Add workflows for creating releases

[jhnstn]

This adds two Github workflows to create release PRs

prepare-release.yml will create a release PR on this repo, Gutenberg Mobile

integrate-release.yml will create an integration release on the specified platform

Both take a release version and the option to specify a gbm-cli version (this can be a tag or a commit on release-toolkit-gutenberg-mobile )

As-is we will need to generate an access token and add it to this repository. There is a PAT_TOKEN there now but I'm not sure if it's still valid. We need a secret named 'GH_ACCESS_TOKEN` that has access to this repo for the prepare commands. The token will have to work with the main app repos for the integration workflow to work.

To test:
Testing will get a bit noisy so it might be best to merge this branch into a fork of Gutenberg Mobile and add GBM_WPMOBILE_ORG and GBM_WORDPRESS_ORG: to the workflow env sections like so:

...
     env:
         GITHUB_TOKEN: ${{ secrets.GH_ACCESS_TOKEN }}
         GITHUB_USER: ${{ github.actor }}
         GBM_WPMOBILE_ORG: {your github user}
         GBM_WORDPRESS_ORG:  {your github user}
...

You will also need a github PAT added to the fork as a repository secret named GH_ACCESS_TOKEN

Then run the prepare worklfow with a version associated with a test release pr on your forked Gutenberg repo

The integration will only work for android in this scenario since iOS will require pods for the release.

PR submission checklist:

• I have considered adding unit tests where possible.
• I have considered if this change warrants user-facing release notes more info and have added them to RELEASE-NOTES.txt if necessary.

[mokagio]

Love seeing some automation.

Have you considered adding to the already existing Buildkite setup?

[jhnstn]

Thanks @mokagio !

Have you considered adding to the already existing Buildkite setup?

I have. This is in part a POC since I don't have much access on Buildkite to try stuff out.

I do think it's convenient to have the Prepare Release as a dispatch workflow here on Github. We can absolutely have the gbm-cli run on Buildkite if there are some advantages there. Just need some core utils but nothing too fancy. I have tried that command on Github and it's significantly slower then running it locally.

But as I mentioned it would be nice to trigger the automation from the the Github Workflow since it can be started remotely. Since our current architecture required pushing changes to Gutenberg, it makes sense to do that and then trigger the workflow after that local script runs. Open to other options but this seems like a good option for now at least.

The Integreate Release workflows should absolutely run on Buildkite. They shouldn't or really can't run until the "publish to s3" steps complete right? So I would love to incorporate those into the Buildkite steps.

[mokagio]

@jhnstn gotcha.

I do think it's convenient to have the Prepare Release as a dispatch workflow here on Github. [...]
But as I mentioned it would be nice to trigger the automation from the the Github Workflow since it can be started remotely.

Was is it that is convenient? Starting the workflow remotely/from GitHub? If that's the case, Buildkite pipelines can be started remotely, too. We do that, for example, in WordPress iOS to run beta and release builds.

I didn't run a comparison to know which provider would be faster, but having all our automation under the same provider would definitely be beneficial. For a start, it's one place to check. But most importantly, all our Buildkite CI infra is managed via Terraform and has various layers of safety, user management, and secrets management.

[jhnstn]

Thanks @mokagio

Buildkite pipelines can be started remotely, too. We do that, for example, in WordPress iOS to run beta and release builds.

I might had been a bit vague when I said "remotely". I specifically meant from the release wranglers local machine.
Would this require a token for a developer to run from their local machine? That was the only piece I figured would add complication. So ideally the same command we run locally to prepare the release on Gutenberg would end with queuing the prepare Gutenberg Mobile job.

That's the advantage I see with using a Github workflow. We can use everyone's Github PAT to trigger the workflow. Beyond that I don't have an opinion on where the job actually runs.

But most importantly, all our Buildkite CI infra is managed via Terraform and has various layers of safety, user management, and secrets management.

Totally get this. And I think we should fold the integrate-release.yml into the Buildkit steps for a few different reasons but security being an important one.

[mokagio]

Would this require a token for a developer to run from their local machine? That was the only piece I figured would add complication.
Yes. We can also automated away managing personal secrets via our internal mobile-secret and configure tooling combo.

We can use everyone's Github PAT to trigger the workflow
So just like the Buildkite token, but from GitHub?

Anyways, once, soon, we'll have our GUI to manage releases, all the storing of token and triggering of automation will live there