[WIP] Add auto-merge-and-tag workflow to promote the release commit to master - #5127
Open
prateekchaudhry wants to merge 1 commit into
Open
[WIP] Add auto-merge-and-tag workflow to promote the release commit to master#5127prateekchaudhry wants to merge 1 commit into
prateekchaudhry wants to merge 1 commit into
Conversation
Today the release commit reaches master by hand: an operator disables
master's branch protection, pushes the stage branch, then re-enables it.
This adds a workflow that performs the same promotion automatically once
the release PR merges into dev, so the protection rule is never disabled
and instead carries a single named exception for the App.
Two jobs:
classify Runs only for a merged v<X.Y.Z>-stage branch whose name
parses as semver. Splitting this out is what produces a
genuine SKIPPED promote for every unrelated PR merged into
dev, rather than a red X or an indistinguishable green.
promote Refuses if the version already has a release or tag, checks
the release commit is reachable from dev, fast-forwards
master to it, extracts that version's CHANGELOG.md section,
then creates the v<X.Y.Z> tag and drafts the GitHub release.
Publishing the draft stays a separate manual step.
The reachability check is the load-bearing one. A squash or rebase merge
mints a new SHA and orphans the release commit from dev, yet master is
still an ancestor of that orphan, so the fast-forward push SUCCEEDS and
master silently diverges from dev. Detection would otherwise be deferred
to the next release's push rejection, after the bad release had shipped.
The App token is minted before actions/checkout and passed via its
token: input, because master will restrict pushes to the App and the
default GITHUB_TOKEN is attributed to github-actions[bot], which is not
on that allowlist. permission-contents: write narrows the token from the
App's full installation scope to the only scope promote needs.
Attacker-influenced event fields (head.ref, head.sha) are passed through
step-level env: rather than interpolated into run: blocks, since ${{ }}
is substituted before bash parses the script.
Requires a paired change to master's branch protection: lock_branch off,
and restrictions set to apps: ["amazon-ecs-bot"]. Until that lands
master is locked to everyone including the App, and promote fails at the
push step.
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Summary
Previously we have added an automation to create release PRs - #4892
This PR continues the release automation effort to "auto merge" release PRs once we have human approvals. The requirement of a release push is to have dev and master in sync.
This has so far been done by merging the release PR -
The result of this is that we have same Git SHAs in both branches. However this process has been manual so far.
This PR automates it using GitHub Actions.
Implementation details
dev, and is split into two jobs.classifydecides whether the merge is a release promotion - the branch must be merged, namedv<X.Y.Z>-stage, and parse as semver. It outputsis_releaseand the version.promotefor every unrelated PR merged intodev, instead of a red X on every merge, or a green that looks the same as a real release.promotedoes what a human does today, in order: check the version isn't already released, fast-forwardmasterto the release commit, extract that version'sCHANGELOG.mdsection, then create thev<X.Y.Z>tag and draft the release with that section as the body. Publishing the draft stays manual.head.sha), so the promotion targets exactly the commit that was reviewed.promotealso verifies the release commit is reachable fromdevbefore pushing. Fast-forward-only looks sufficient here but isn't - a squash or rebase merge creates a new SHA and orphans the release commit, andmasteris still an ancestor of that orphan, so the push would succeed and leavemasteron a linedevabandoned. Without this check we would only find out at the next release.APP_ID/APP_PRIVATE_KEYsecrets), minted before checkout so the push tomastercarries the App's credentials rather than the defaultGITHUB_TOKEN.Please note: this needs a paired update to master's branch protection so the App is allowed to push. Until that is applied,
promotewill fail at the push step - nothing is tagged or drafted andmasteris not moved, so the manual process still works as it does today, and the job can be re-run once the protection update is in place.Testing
Tested on my fork with protected
devandmaster, running the real two-workflow chain -create-release-prto open the release PR, then merging it to trigger this one.masterto the release commit, created the tag and drafted the release with the changelog section as its body.devandmasterended up with the same SHA. Release PR: Release 9.99.10 prateekchaudhry/amazon-ecs-agent#43devleft both jobs skippedNot verifiable on a fork: app-level push restrictions can't be configured on a personal repo, so the "only the App can push master" part is only exercisable here.
New tests cover the changes:
No - workflow change
Description for the changelog
Housekeeping: add an action to automate merging release PRs to master.
Additional Information
Does this PR include breaking model changes? If so, Have you added transformation functions? N/A
Does this PR include the addition of new environment variables in the README? N/A
Licensing
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.