search

WordPress / gutenberg

The Block Editor project for WordPress and beyond. Plugin is available from the official repository.
https://wordpress.org/gutenberg/
Other
10.51k stars 4.21k forks source link

Tracking issue: Plugin build and release workflow improvements #53303

Open ockham opened 1 year ago

ockham commented 1 year ago

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

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):

Pasted Graphic

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?

image

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:

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 https://github.com/WordPress/gutenberg/pull/49082#discussion_r1221672011.

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 https://github.com/WordPress/gutenberg/pull/55608

Mamaduka commented 1 year ago

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 commented 1 year ago

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.