Description

Follows bin/plugin/commands/release.js.

The idea here is to couple the upload of the Gutenberg plugin to the WP.org plugin repo tightly to when a new release is published to GitHub, rather than running it from the local system of whoever's in charge of releasing that version.

Moving parts of the release workflow from locally running scripts to GH actions should overall make the process more easily reproducible, and should free up time and resources required for the release process.

The parts that would normally actually upload to the SVN repo are still commented out, since they need credentials -- I put a few echos instead. These credentials will need to be set as secrets in GitHub's settings.

If we want to merge this PR, we'll need to remove the parts from the local release script that are in charge of uploading to svn, so that we won't upload twice (once from the script, once from the GH action).

How has this been tested?

See here for an example run: https://github.com/ockham/gutenberg/runs/1643670225?check_suite_focus=true

Or use the following instructions to test for yourself:

• Make sure you have your own fork of the Gutenberg repo, and that you've added it locally as a remote (E.g. git remote add ockham git@github.com:ockham/gutenberg.git if your GH username is ockham 🙂 ).
• Check out this PR's branch, and push the contents to your fork's master branch (you can reset later):

git push ockham add/svn-upload-gh-action:master

• Publish a release in your fork (under 'Releases', e.g. https://github.com/ockham/gutenberg/releases). Make sure to attach a gutenberg.zip as an asset (e.g. downloaded from the WP.org SVN plugin repo). For the release name, use a version number like 1.2.3 (with no leading v).
  • You might have to pick a tag to create the release for -- just choose any. If you're told that there already exists a release for each tag you try, create your own. (git tag v9.9.0-rc.1 and git push --tags ockham)
• Go to the 'Actions' tab of your fork's GH page (e.g. https://github.com/ockham/gutenberg/actions).
• Locate the action whose description reads "Upload Gutenberg plugin to WordPress.org plugin repo", and click on it.
• It should only take a few seconds to perform the operations from this action.
• Inspect the individual steps of the workflow (by expanding them) to verify that they worked.
• Don't forget to clean up tags after running these commands, so you won't accidentally push tags that you solely created for testing to the actual Gutenberg repo later. See e.g. https://stackoverflow.com/questions/1841341/remove-local-git-tags-that-are-no-longer-on-the-remote-repository

(I've used my Gutenberg fork as an example, you can see the relevant action and release drafts from previous runs there.)

Screenshot

Types of changes

Build automation

Future ideas

Combine with #27488 for an even more automated release workflow

This PR covers the parts that happen after a GH release (with the plugin zipball attached as an asset) is released. I have a companion PR that covers the parts before: #27488 kicks in when a version tag is pushed to the repo. It builds the plugin zipball, creates a draft release, and attaches the plugin zipball as an asset. Merging both PRs could minimize the part of the release workflow that's done on a local machine to updating the changelog, and tagging.

Publish as reusable GH action

If this proves useful, it might make sense to publish it as a more generic GH action that looks for a zip asset attached to a release, and uploads it to the WP.org plugin repo. A similar action exists, but it has an important difference to this:

It uploads a snapshot of the files in the repo that correspond to a tag, rather than the files found in a zipball. Files can be excluded from upload via .gitignore and a .distignore. I'm not sure this sort of customizability is sufficient for GB, where we're more selective in picking our files. Generally, I think it's more versatile to use a zipball as the "input" for an action like this.

Furthermore, it's Docker-based, which I don't think is strictly necessary.