Setup plugin deploy GitHub Action

[adamziel]

@aristath, setting up this action would make new releases super easy:

https://github.com/10up/action-wordpress-plugin-deploy

[ashfame]

@aristath 👋 I have been meaning to contribute the elaborate setup we have for releasing plugins to WP.org repo to this repo, which also uses 10up/action-wordpress-plugin-deploy action linked by Adam above. Here's the Link to full instructions for issuing releases that we use on WP OIDC & Chatrix & a quick summary below:

• Use a script to bump up version number in files and create a draft PR with those changes using gh cli.
• Commit changelog in readme at this point
• Merge PR, which triggers next step
• Draft release on Github is created
• Review and publish the release, which triggers the next step
• Release is published on WP.org repo 🥳

Could you shed some light on how new releases are currently done? The described setup requires a svn password for an account with access in Github repo secrets. Would this or a trimmed version be a nice addition to automate issuance of releases at this point?

[JanJakes]

Thanks, @ashfame, this will be super helpful!

I wonder if we could simplify this even further so that the first step is triggered by a draft release.

Not sure if it makes sense, but a draft release with a new tag creates that new tag only when the release is published, which could allow for the following workflow:

1. Create a draft release.
2. A GitHub action picks up the draft release, and prepares a pull request with version bumps (based on the new tag to be created) and changelog inserted into readme (taking the changelog from the draft release).
3. Merge the PR.
4. Publish the draft release, which automatically pushes it to WP.org repo.

I'm not 100% certain that this is possible (that a draft release provides the drafted tag name, for example), but it would make releasing a new version very close to just drafting and publishing a GitHub release. and the new tag and changelog would be specified when drafting the release.

[zaerl]

The 10up/action-wordpress-plugin-deploy flow is used in all OSS core importers, for example, the WordPress importer, and is working great.

The actual procedure used in the importers needs these manual steps:

1. Bump the version on the main plugin file top comment. Put the same version in the “Stable tag” field of readme.txt. Add a new entry in the == Changelog == section of readme.txt (see https://github.com/WordPress/wordpress-importer/pull/175/files)
2. Create a new release with the version of the plugin on GitHub. The title should be “Version x.y.z” and your changed content. (Example here)
3. A team member with wporg access must approve the new version in wporg dashboard
4. Check the plugin page and the SVN page and ensure that a new tag with your version has been created.

But points 1 and 2 can be automated by a script similar to the (old) wpcomsh one.

[ashfame]

@JanJakes The reason why I like what we have more is that it explicitly begins with a tiny script changing the version number in code files bin/prepare-release.sh 1.2.3.

The resultant PR with that change includes a link in description to review code changes since last tagged version easily. Github AI button lets you generate the summary of changes very quickly, which can be copied to release description exactly. Additionally, this also allows everyone to be notified with the intent of releasing PR by just tying it all to the flow of a PR review. So, others can comment or mark the PR as approved and only then the ball starts rolling.

It's actually pretty much how @zaerl describes it.