Tracking issue: Plugin build and release workflow improvements

[ockham]

Over the last weeks and months, and specifically when assisting @fullofcaffeine with #49082, I've noticed a few things in our plugin build GHA workflow that could use some tweaking. I'll start a list here; we might eventually convert individual items into separate issues.

Bugs

• Tools: New tag for plugin release not created successfully on svn #55295

De-duplication/delegation to GH releases functionality

Changelog creation

Our workflow currently uses a script to generate the changelog.

Remove duplicated Contributors section

We're using a function to include a list of contributors that contributed to a given Gutenberg release. However, GitHub now includes this information itself in a given release's notes (the one with the avatars at the bottom):

We might thus consider removing our own list altogether.

Let GH generate the release notes

Maybe we can delegate release notes generation to GH altogether: The release creation form now has a button titled "Generate release notes". Maybe folks in charge of a GB release could use that button; or maybe this functionality is even exposed through the REST API endpoint that we use for release draft creation?

Edit: Looks like changelog creation can at least be configured to some extent.

Code organization/quality

Code organization

We might want to organize our workflows a bit better, to better encapsulate and colocate jobs that are related, and to separate other concerns. This will likely require an audit of what we currently have. Questions to ask ourselves might include:

• What's the best way to organize the plugin build workflow? We need a plugin build in two separate cases:
  • On every PR, to have a plugin zip with the PR code available.
  • When publishing a new release. This also involves a version bump etc.
    Currently, both scenarios share one workflow file. Can we maybe organize this better? Could reusable workflows help here? Or can we maybe encapsulate some logic into smaller, reusable GH actions?

De-dupe tag/trunk publishing

#49082 introduced publishing directly to a remote tag, but duplicates quite a lot of logic that's used when publishing both to trunk and then copying the latest trunk to a newly created tag. Maybe we can flip things around by always creating the tag first, and only copying that to trunk in case we're publishing the latest release. (Curious to hear your thoughts on this, @fullofcaffeine)

npm publishing logic

The npm publishing logic currently lives in the build-plugin-zip.yml workflow. Maybe it'd be better to move it into a separate workflow, or into upload-release-to-plugin-repo.yml (and potentially rename the latter to publish-plugin-and-npms.yml).

Cleanup

Use semver npm to compute versions in plugin upload workflow

See #49082 (comment).

Longer-term goals

A stretch goal could be to provide a reusable workflow (or set of GH actions) for plugin authors to use so they can easily publish their own GH-hosted plugins to the WordPress.org plugin repo. 10up has something similar, but it had a few shortcomings last I checked.

I think it didn't e.g. allow specifying a build directory, but that seems to have been added in the meantime. Maybe we should consider using that GH Action? Potentially in conjunction with 10up/action-wordpress-plugin-asset-update to update the stable version field in the readme.txt.

Experimental PR at #55608

[Mamaduka]

Let GH generate the release notes

That would be great, especially if we could provide a template for GH that matches the current release notes.

Some of that data is re-used in the release posts, like the custom contributor list. We should keep that in mind.

[gziolo]

The npm publishing logic currently lives in the build-plugin-zip.yml workflow. Maybe it'd be better to move it into a separate workflow, or into upload-release-to-plugin-repo.yml (and potentially rename the latter to publish-plugin-and-npms.yml).

It's fine to move the job wherever it logically fits better. The only requirement is that it should trigger just after the branch for the plugin release gets prepared.