Automate publishing process via CI

[mtrezza]

New Feature / Enhancement Checklist

• I am not disclosing a vulnerability.
• I am not just asking a question.
• I have searched through existing issues.

Current Limitation

Currently, publishing a new version of the Parse Flutter SDK on pub.dev is done manually. This poses several issues:

• Inefficient, as manual steps are required
• Possible divergence of GH versions and pub.dev versions
• Separate permissions management, instead of managing publishing permission as part of GH team permissions

Feature / Enhancement Description

Automate publishing process via GitHub CLI, analogous to, for example publishing parse-server on npm.

TODOs:

• Add auto-publishing to pub.dev (triggered on GitHub release) ci: automate publishing to pub.dev #719
• Validate by creating a manual release (3.1.x or 3.2.0) -- version tag without V prefix!
• Add auto-release workflow (branch renaming, changelog-generation, etc)
• Validate by creating a automatic release via PR-merge

Example Use Case

n/a

Alternatives / Workarounds

n/a

3rd Party References

n/a

[mtrezza]

@RodrigoSMarques It would be great if you could have a look into this, since you seem to be most familiar with the pub.dev publishing process. I am of course available to assist from the GitHub CI side. I think a good starting point would be to look at the parse-server workflows, specifically, the release flow.

cc @phillwiggins

[fischerscode]

@mtrezza @RodrigoSMarques
If you want, I could have a look at this, too.

[fischerscode]

Some more information as I'm now home:

Currently there is no recommended way to publish dart/Flutter packages to pub.dev automatically. The community uses the access and refresh token pub publish created at the first publish. Technically those tokens are not package but account bound and belong to the personal account. This meas, although they work for publishing, in theory they are a security risk, as someone with push access to this repo could extract the (GitHub) Secret containing those tokens and use them in order to authenticate as the user who created them.
As an example: If @RodrigoSMarques would create the GitHub Secrets using his personal account, anybody who has push access to this repo could steal those and publish to his package.
Please note: This is just theory and I don't think anybody would do such a thing (right?) esp. as the fake release could be easily reverted by the pub.dev team. But never the less, it is worth considering the potential risk.

The options I see:

1. Accept the risk and use the this action. (Publish CI as soon as possible)
2. Create a Google Account that has just access to those packages. (Nothing relevant could be stolen.)
3. Publish manually until an official way to publish using CI is added. See this issue (Personally I am using this way for a small package.)

Some thinks the automation should do:

• On pre-release: make sure to only publish prereleases. (Check version)
• On release: makes sure not to publish as a prerelease. (Check version)
• Release the dart package first and the flutter package second (might fail otherwise as flutter might/should depend on dart).

[mtrezza]

@fischerscode Thanks for the analysis.

Yes, for now we'll publish manually until we found a feasible way to automate this.

We should do a careful risk analysis regarding automated publishing and permission exposure. The risk is not only malicious intent by a single person, but maybe more accidental actions or compromised 3rd party accounts, because we cannot control how someone stores their own account credentials.

@RodrigoSMarques Do you have a next release planned, where we can test how we coordinate a manual release?

[Mabenan]

Maybe i can give some new information on stealing secrets from github actions as i already tried this myself to get a lost key back. First of it is not so easy as every secret used in github actions can not be simply printed. I only could get by echo it to a txt file and upload this text file somewhere. Maybe we there are ways of securing the access to the secrets by restricting the environment to branches (or maybe cleanup and restrict the branch creation all together) and then restrict the merging to these branches.

[mtrezza]

We already use GitHub secrets for NPM and docker publishing token in other repos; we can assume the feature is safe as that is exactly what it's designed for. As I understand it, secrets are only accessible on the original repo branches, not on fork branches or PRs. We just have to be careful about what we merge, but that we have to be anyway.

That is one of the reasons we changed the permission model in our repos and are now giving only a select few people write access to the repositories, where before, every org member had write access.

[RodrigoSMarques]

Hi @mtrezza.

How can I contact you so we can talk about releasing new versions of the package?

Since Phil left the project we haven't published any updates, because I don't know how the process was defined.

I believe that as the package is now publisher verified, you could invite me to publish the version.

I await your contact.

[mtrezza]

Maybe we can already set up the CI to automate the publishing in the future? Do you want to look into that and open a PR for a GitHub workflow? Feel free to contact me on Slack.

[RodrigoSMarques]

Hi @mtrezza .
I was away for vacation.

I don't know if there is an option for automated deployment.

My sugestion. Do the update manually and then try to automate.

We have several bugs to be updated and as I have other projects, time is limited to check before the update.

My sugestion. Do the update manually and then try to automate.

We have several bugs to be updated and as I have other projects, time is limited to check before the update.

In this issue we have the analysis about the deployment automation.

[mtrezza]

Sure, @RodrigoSMarques I think we could give you temporary maintainer access if you would be willing to publish a release? Then we have more time to figure out how to automate this.

[mtrezza]

@RodrigoSMarques Friendly ping in case you overlooked my previous comment.