-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Release Workflow: Allow triggering manually #28138
Conversation
Size Change: +3.58 kB (0%) Total Size: 1.4 MB
ℹ️ View Unchanged
|
579907d
to
ab4ce92
Compare
ab4ce92
to
101b51a
Compare
101b51a
to
fdd6683
Compare
…8424) The Changelog generator script, `bin/plugin/commands/changelog.js`, currently doesn't support patch releases: It's only possible to generate a Changelog for a given milestone (which are per-minor-release, i.e. per-release-branch), but not on a more fine-grained basis. If the Changelog script is run for a patch release, the generated Changelog includes everything from the `.0` stable release from that series up to the patch release. This PR adds an `--unreleased` option to the Changelog script that makes it look up the latest release in the series, and only includes issues that were modified after that release was published. This will allow us to use the script to generate the Changelog for patch releases (or at least a baseline -- see 'Discussion' for a caveat). This will come in handy as we automate more and more parts of the build process -- especially to auto-generate a Changelog for patch releases, and to pre-populate the corresponding release notes. (Cf. #28138.)
a22c475
to
a7a3730
Compare
There's one functional change to the release GH workflow included in this PR: Rather than publishing the release right away, only create the draft, and let a human publish it. The reason for this is twofold: - The SVN upload action didn't trigger when the release was published. This is because [GH workflows don't trigger other GH workflows](https://docs.github.com/en/actions/reference/events-that-trigger-workflows#triggering-new-workflows-using-a-personal-access-token) (to avoid recursions). (The workaround was to set the release to pre-release status, and then back.) - This aligns better with the changes planned in #28138 anyway (where we'll remove the local build script altogether; instead, editing the release draft will be the opportunity for the release manager to actually edit the auto-generated changelog before publishing). Changes to `release.md` thus include: - A description of the GH-side steps: - Locate the release draft, edit and publish it. - The SVN upload action needing approval. - Commit access to SVN no longer needed. Instead, a member of the `gutenberg-core` team needs to approve the upload. - ~Two days~ -> One week between RC and stable release. Finally, instructions in the `release.js` script are updated accordingly. (Keep in mind that that script is slated for removal once #28138 lands).
01f7063
to
b152390
Compare
d025b6d
to
b84b85f
Compare
e6ecf79
to
d500373
Compare
Okay, I think this is about ready for review. I've limited this to only work if the I still need to update the PR description a bit, and maybe provide a better gif or video to demo it. But that's for next week. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we remove the release script and update the docs here or as a follow-up?
Ah, good spot! I'll take care of that. |
Might be worth doing here 👍 |
@ockham curious, how have you tested the svn part? So far I am using a dummy repo on SourceForge (working on automation for a plugin as well), but perhaps there's a better way. |
I'm afraid I haven't found a better way myself yet -- I'm using a dummy repo that I created at https://riouxsvn.com (thanks to a tip from @jorgefilipecosta). |
Addressed in fc79221. |
Done in the past couple of commits. |
Description
Allow manual triggering of the workflow to create a new release, per this discussion.
The end goal is for the release manager to run the entire release process from GitHub, and to minimize manual interaction.
changelog.txt
, uploads Gutenberg plugin and updatedchangelog.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.Demo
https://youtu.be/TnSgJd3zpJY
How has this been tested?
See here for an example release created by this action: https://github.com/ockham/gutenberg/releases/tag/v10.2.0
Corresponding workflow run: https://github.com/ockham/gutenberg/actions/runs/654286491
Or use the following instructions to test for yourself:
git remote add ockham git@github.com:ockham/gutenberg.git
if your GH username isockham
🙂 ).trunk
branch (you can reset later):trunk
branch as the base branch, and specify eitherstable
orrc
to release create a stable or release candidate version of the plugin.gutenberg.php
,package.json
, etc), and that the Changelog contains the release notes for the release.changelog.txt
on bothtrunk
, and the release branch.(I've used my Gutenberg fork as an example, you can see the relevant action and release drafts from previous runs there.)
Follow-up: