GitHub Actions: Create Release Draft when tagging version #27488
Conversation
|
Size Change: -26 B (0%) Total Size: 1.3 MB
ℹ️ View Unchanged
|
ockham
force-pushed
the
add/gh-action-create-release
branch
from
272bef6 to
9f9d17f
Compare
ockham
force-pushed
the
add/gh-action-create-release
branch
2 times, most recently
from
987a7bc to
e8db557
Compare
ockham
requested review from
ajitbohra,
karmatosed,
mapk,
nerrad and
ntwb
as code owners
Can we remove the remaining local step by making it a "manual workflow" (workflow_run) we could trigger from the actions page.
I think it makes sense to publish it. So if I understand properly this is only for stable releases right, how do we go about doing the same thing for tags like v9.6.0-rc.1 and mark the corresponding Github releases as "pre-release" ? |
I'm not sure we can do that, since the local step is still required for giving the developer a chance to provide a changelog, no?
Okay, I'll change that 👍
The action already does that: https://github.com/WordPress/gutenberg/pull/27488/files#diff-40b47d855e2cffe931290bba37c1b8716642627cbe05ac859728cb95c5da7536R81 😎 |
Some context: The new action tightly couples release creation to tag creation (or rather, pushing a tag to the repo). This seemed to make sense to me, as we have kind of an invariant here: For every tag (that starts with a There are basically two reasons the local script is still required: Tag (and release branch) creation, and providing a prompt for the changelog. The need for the latter mostly results from the fact that we keep We can loosen that requirement as follows (but this is something I'd tackle in a subsequent PR, as it requires some more discussion and agreement): We drop This would allow for the following release flow, which personally I'd find the most streamlined: My preferred end goal for the release flow is as follows:
At that point, we might not actually need a local release script anymore, as all it would do would be release branch and tag creation, which are arguably easy enough to do manually. |
ockham
force-pushed
the
add/gh-action-create-release
branch
from
f34c0af to
11c25c7
Compare
|
I think at this point, I see things a bit differently, here's what would be the ideal end goal for me: 1- Go to Github actions, and choose whether to perform an RC release or a stable release. (could be separate jobs) IF RC:
IF Stable:
In both situations, the "release manager" only had to interact once. Click the initial job to perform the release. In your proposal, it's not clear how the release branch gets created. It's also adds extra steps to the process. WDYT |
That said, I'm fine with keeping the release script for now as the replacement of the first part of this (provide changelog, create release branch and tag) and let the action continue from there. It's still just one step to be done but locally. |
Thanks! Yeah, so the goal of the current PR was to trim down time spent on the build process locally, by moving it to the GH action. Otherwise, it doesn't really change the developer experience -- I was thinking of it as a stepping stone for future changes. |
Thanks for clarifying 👍
Yeah, they probably would need to be separate jobs 🤔
Through regular git commits?
I'd probably do that manually. I agree that my proposal differs a bit on the philosophical front: I'd say that yours is a one-stop shop solution -- which is admittedly very convenient for release managers 😄 Mine encapsulates the GB-specific build and upload parts into actions that are tightly coupled to tag creation -- thus emphasizing the role of the latter -- and exposes the more 'generic' git parts, requiring the release manager to manually create the release branch and tags. The reason why I prefer the latter is because it gives us more flexibility, and because I believe we cannot (nor should we) shield developers entirely from some (not very advanced) git operations. After all, AFAIU, developers will also need to potentially cherry-pick commits from
I find the latter preferable. This is just the workflow we're typically dealing with now. The added flexibility of the second scenario pays off even more if we ever wish to modify that workflow. Imagine e.g. someone would want to publish a point release to a previous version 😬 Or any other change to the process, really.
See above for the rationale about git related steps. There's still room to minimize the number of steps further, if we don't want to require the release manager to press 'Publish' on the release -- I think we can include the steps for release note creation that you describe into the current workflow. That said, I don't think the 'optimal' workflow is solely measured in number of steps: I think it's okay to include an extra step if it
Happy to discuss this further so we can find a good solution that we both -- and everyone else -- likes 😄 Sorry that this turned out a bit more verbose again. (I've actually written some internal documentation on this very subject before, I'll try to find it.) |
Just by editing the release on github
I think I'm in disagreement with this because I want to be able to say anyone can do a release. And the number of times people ask on which branch they should be to do such thing or such other thing is high for me. I feel it's not really about folks not having the skills but more about removing pressure from folks to have to know exactly what they should be doing and blaming the tools if there's an error instead. Basically what I want is not saying to folks "go head these docs" to perform the release but just "go there and click there" or "just run this, it will tell you what to do". I want to remove the stress factor and the possibility to make errors from the release manager. But I also agree that we should ask the folks that did previous releases their opinion on this. |
|
The release is now published (after attaching the asset), see https://github.com/ockham/gutenberg/runs/1681775057?check_suite_focus=true for a test run (and https://github.com/ockham/gutenberg/releases/tag/v9.7.0 for the resulting release). I'll change the copy in the release script now. |
|
Build Gutenberg upon creating a tag that starts with `v`, and creating a draft release with the build attached to it. Furthermore, extract the changelog for the current release from `changelog.txt`, and use it to populate the release notes. The (locally run) release script works pretty much as before -- only plugin zip creation and GitHub release creation have been removed (since they're now done by the new workflow). The main benefit of this is that the plugin build is decoupled from people's local systems and setups, yielding reproducible builds, and cutting down time spent running the release process locally (freeing up people's systems earlier). (One micro-optimization is e.g. that it's no longer necessary to enter a GH access token during the release process.)
Late to the party, but I like the idea that anyone should be able to do a release. That said, I find the hardest part of the process (assuming tooling works correctly) to be editing the changelog and writing the release post, and I suspect these tasks will be nearly impossible to anyone who isn't reasonably familiar with the repo and with ongoing work, priorities, etc. For feedback going forward, perhaps a post on make/core would help? Also, let's not forget to update the release docs with the latest changes! |
Late to reply myself now -- apologies, I let this fall through the cracks.
Agree, the 'editorial' part of a release is hardest.
I'm planning one. Overall, once I've finished my little tool automation project (mostly #28138 at this point), I'd like to publish a post about the (hopefully) simplified release process; and to describe the role of a release manager, which would include that 'editorial' part, plus being responsible for bug fixes and patch releases over the lifecycle of a version. (This has been partly discussed with @mcsf et al).
I've been a bit slow with this one since I hoped to do it all in one fell swoop once I'm done with #28138, but since that has been dragging out a bit, here goes a doc update that reflects the current state: #29091. |
Allow manual triggering of the workflow to create a new release, per [this discussion](#27488 (comment)). The end goal is for the release manager to run the entire release process from GitHub, and to minimize manual interaction. - ✋ Release manager starts release process manually. - 🤖 GitHub workflow bumps version numbers in plugin files, builds Gutenberg plugin, creates release draft, and prefills it with release notes based on changelog script output. - ✋ Release manager edits release draft, and eventually publishes it. This creates the tag. - 🤖 (Other) GitHub workflow prepends release notes to `changelog.txt`, uploads Gutenberg plugin and updated `changelog.txt` to WP.org plugin repo. Functionally, this is as close as possible to the previous workflow. The major difference is that `changelog.txt` is only updated _after_ tagging. This is a result of using the GitHub release draft UI to edit and revise release notes. It's not possible to include the result of those changes _before_ tagging. Release docs are updated to reflect these changes. The previously used local release script is removed.
Description
Second stab at writing a workflow (GitHub action) to build Gutenberg upon creating a tag that starts with
v, and creating a draft release with the build attached to it. Supersedes #19626.The difference to #19626 is that:
The (locally run) release script works pretty much as before -- only plugin zip creation and GitHub release creation have been removed (since they're now done by the new workflow).
Note that we're currently creating a release draft, meaning an extra step is required to publish the release: Clicking the 'Publish' button. While I find that extra safety net convenient, it is mainly for testing purposes. I'm happy to change it to publish the release right away -- it's only a one-line change (plus a few instructions in the release scripts).
The new GH workflow uses the following GH actions:
The main benefit of this PR is that the plugin build is decoupled from people's local systems and setups, yielding reproducible builds, and cutting down time spent running the release process locally (freeing up people's systems earlier). (One micro-optimization is e.g. that it's no longer necessary to enter a GH access token during the release process.)
How has this been tested?
See here for an example release draft created by this action: https://github.com/ockham/gutenberg/releases/tag/untagged-f7f779e5825df118d22c
Corresponding workflow run: https://github.com/ockham/gutenberg/runs/1670519325?check_suite_focus=true
Or use the following instructions to test for yourself:
git remote add ockham git@github.com:ockham/gutenberg.gitif your GH username isockham🙂 ).masterbranch (you can reset later):git tag -d v9.7.0) and in your forkgit push ockham :v9.7.0.git tag v9.7.0.git push --tags ockham.(I've used my Gutenberg fork as an example, you can see the relevant action and release drafts from previous runs there.)
Alternatively, you can also use the local release script to create the tag and changelog. Make sure to modify
bin/plugin/config.jsto point to your forked repo!Types of changes
Build tools automation