Skip to content
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

Merged
merged 9 commits into from
Jun 23, 2021

Conversation

ockham
Copy link
Contributor

@ockham ockham commented Jun 9, 2021

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

image

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 after 10.9.0-rc.1 had already been created. Note that the version bump commit was only pushed to the release/10.8 branch, but not trunk.

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/950185263

Types of changes

Releases tooling.

@ockham ockham added the [Type] Build Tooling Issues or PRs related to build tooling label Jun 9, 2021
@ockham ockham self-assigned this Jun 9, 2021
@ockham ockham mentioned this pull request Jun 18, 2021
7 tasks
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)
@ockham ockham changed the title Workflows: Allow later point releases Workflows: Allow point releases after a new RC is out Jun 18, 2021
@ockham ockham marked this pull request as ready for review June 18, 2021 14:24
@ockham ockham requested review from desrosj and a team June 18, 2021 14:25
@ockham ockham requested a review from Mamaduka June 21, 2021 12:44
Copy link
Contributor

@youknowriad youknowriad left a 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' }}
Copy link
Contributor

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?

Copy link
Contributor Author

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 😉).

Comment on lines +58 to +59
endsWith( github.ref, needs.compute-stable-branches.outputs.current_stable_branch ) &&
github.event.inputs.version == 'stable'
Copy link
Contributor Author

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

Copy link
Contributor

@mcsf mcsf left a 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. :)

@ockham ockham merged commit 0d7102e into trunk Jun 23, 2021
@ockham ockham deleted the update/workflow-to-allow-later-point-release branch June 23, 2021 17:55
@github-actions github-actions bot added this to the Gutenberg 11.0 milestone Jun 23, 2021
ockham added a commit that referenced this pull request Jun 25, 2021
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).
@ockham
Copy link
Contributor Author

ockham commented Jun 25, 2021

Cherry-picked to release/10.9 (in case we end up needing it later).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Type] Build Tooling Issues or PRs related to build tooling
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants