Release Workflow: Allow triggering manually #28138
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Size Change: +3.58 kB (0%) Total Size: 1.4 MB
ℹ️ View Unchanged
|
ockham
force-pushed
the
update/trigger-release-workflow-manually
branch
from
579907d to
ab4ce92
Compare
ockham
force-pushed
the
update/trigger-release-workflow-manually
branch
from
ab4ce92 to
101b51a
Compare
ockham
force-pushed
the
update/trigger-release-workflow-manually
branch
from
101b51a to
fdd6683
Compare
ockham
added a commit
that referenced
this pull request
Feb 17, 2021
…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.)
ockham
force-pushed
the
update/trigger-release-workflow-manually
branch
2 times, most recently
from
a22c475 to
a7a3730
Compare
This was referenced Feb 24, 2021
ockham
added a commit
that referenced
this pull request
Feb 25, 2021
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).
ockham
force-pushed
the
update/trigger-release-workflow-manually
branch
from
01f7063 to
b152390
Compare
ockham
force-pushed
the
update/trigger-release-workflow-manually
branch
3 times, most recently
from
d025b6d to
b84b85f
Compare
ockham
force-pushed
the
update/trigger-release-workflow-manually
branch
from
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. |
youknowriad
reviewed
Mar 16, 2021
youknowriad
reviewed
Mar 16, 2021
youknowriad
approved these changes
Mar 16, 2021
Ah, good spot! I'll take care of that. |
Might be worth doing here 👍 |
swissspidy
reviewed
Mar 16, 2021
swissspidy
reviewed
Mar 16, 2021
|
@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. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.txtto WP.org plugin repo.Functionally, this is as close as possible to the previous workflow. The major difference is that
changelog.txtis 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 [email protected]:ockham/gutenberg.gitif your GH username isockham🙂 ).trunkbranch (you can reset later):trunkbranch as the base branch, and specify eitherstableorrcto 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.txton 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: