-
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
Workflows: Allow point releases after a new RC is out #32560
Conversation
Most of these job are only run manually anyway, so we shouldn't need to prohibit them from running on forks. Furthermore, these checks make it much harder to test changes to this workflow on a fork. See #32114 (comment)
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.
I tried to follow the logic in the code but failed to understand it properly :P
run: | | ||
git add gutenberg.php package.json package-lock.json readme.txt | ||
git commit -m "Bump plugin version to ${{ steps.get_version.outputs.new_version }}" | ||
git push --set-upstream origin "${{ steps.get_version.outputs.release_branch }}" | ||
|
||
- name: Cherry-pick to trunk | ||
- name: Fetch trunk | ||
if: ${{ github.ref != 'refs/heads/trunk' }} |
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.
I guess this is the important change right? Preventing the cherry-pick if we don't use trunk as a base branch?
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.
Ah no, not really, we were doing that before -- just using a different heuristic, i.e. by checking whether the version in trunk
's package.json
matched the one from the branch the workflow was triggered from 😬
However, we limited at the time which branches the workflow could be triggered to trunk
only, so the check was a bit academic (and arguably a violation of the YAGNI pattern, that I hold so dear 😉).
endsWith( github.ref, needs.compute-stable-branches.outputs.current_stable_branch ) && | ||
github.event.inputs.version == 'stable' |
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.
This is the crucial change: We're now also allowing to run this job from the "current stable branch", i.e. the branch the latest stable release belongs to (e.g. the release/10.8
branch, if the latest release is 10.8.2
); but only to release a new stable (i.e. point) release (e.g. 10.8.3
).
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.
Lots of GH juggling, thanks for persisting. Let's see how it goes. :)
Our plugin release workflow currently allows publishing point releases only for the current version range. However, we've recently faced a situation where we had to publish a point release for a series (10.7.x) after the release candidate for the next series had already been published (10.8.0-rc.1). Since our automated workflow didn't allow for that, we had to take care of the plugin build manually 😕 This PR aims to allow publishing point releases for older version ranges, by selecting the relevant branch from the `workflow_dispatch` trigger dropdown. It's fairly straightforward to cover the scenario described above, so for starters, this PR will only allow that. Allowing publishing of point releases even later (after a new _stable_ release has been published) will require more work (mostly on the SVN side of things -- probably will need the concept of SVN release branches, in order to keep SVN history intact).
Cherry-picked to |
Description
Our plugin release workflow currently allows publishing point releases only for the current version range. However, we've recently faced a situation where we had to publish a point release for a series (10.7.x) after the release candidate for the next series had already been published (10.8.0-rc.1). Since our automated workflow didn't allow for that, we had to take care of the plugin build manually 😕
This PR aims to allow publishing point releases for older version ranges, by selecting the relevant branch from the
workflow_dispatch
trigger dropdown.It's fairly straightforward to cover the scenario described above, so for starters, this PR will only allow that. Allowing publishing of point releases even later (after a new stable release has been published) will require more work (mostly on the SVN side of things -- probably will need the concept of SVN release branches, in order to keep SVN history intact).
Screenshots
How has this been tested?
On my fork: https://github.com/ockham/gutenberg/actions/runs/950100605
I've used this to create a
10.8.1
point release after10.9.0-rc.1
had already been created. Note that the version bump commit was only pushed to therelease/10.8
branch, but nottrunk
.Conversely, when attempting to publish an RC on an already-stable branch (
release/10.8
), the version bump and release draft creation jobs aren't run: https://github.com/ockham/gutenberg/actions/runs/950185263Types of changes
Releases tooling.