Add auto-merge-and-tag workflow to promote the release commit to master - #5127
prateekchaudhry wants to merge 1 commit into
Conversation
453a6eb to
6f8f3fe
Compare
prateekchaudhry
changed the title
6f8f3fe to
e64f89c
Compare
6b9aa18 to
97f97cb
Compare
| if gh release view "v${AGENT_VERSION}" --repo "${{ github.repository }}" >/dev/null 2>&1 || \ | ||
| gh api "repos/${{ github.repository }}/git/refs/tags/v${AGENT_VERSION}" >/dev/null 2>&1; then | ||
| echo "::error::Version ${AGENT_VERSION} already has a GitHub release or a v${AGENT_VERSION} tag. Delete whichever exists (a draft release has no tag yet) and re-run this workflow." | ||
| exit 1 |
There was a problem hiding this comment.
Q: Do we want some kind of alarming when this github action fails like we do for our other automated github workflows?
There was a problem hiding this comment.
Completion of GH Action will be manually verified by the person who creates the release PR, as that step is manual. I don't think we should need to add alarms here as long as we document this properly.
There was a problem hiding this comment.
Hm I see, thanks. I was under the impression that the PR merge will be done manually and then these will take care of the sync to master for us automatically.
| found && /^# / { exit } | ||
| found { print } | ||
| ' /tmp/full-changelog.md > /tmp/release-notes.md | ||
| # Test for real content, not file size: an empty section yields a blank line, which -s counts as non-empty. |
There was a problem hiding this comment.
We may want to move this logic to the release PR generation if it's not already there so that it can catch this sooner rather than at this point of the release. Or is this more of a defense check?
There was a problem hiding this comment.
This is a validation check here.
But it is a good candidate to be added in PR Generation script as well, currently we have it at warning there. We can add it as a different change.
| # gh release view only finds a Release object; check the tag itself too, since a tag can survive a deleted release. | ||
| if gh release view "v${AGENT_VERSION}" --repo "${{ github.repository }}" >/dev/null 2>&1 || \ | ||
| gh api "repos/${{ github.repository }}/git/refs/tags/v${AGENT_VERSION}" >/dev/null 2>&1; then | ||
| echo "::error::Version ${AGENT_VERSION} already has a GitHub release or a v${AGENT_VERSION} tag. Delete whichever exists (a draft release has no tag yet) and re-run this workflow." |
There was a problem hiding this comment.
Q: Do we want to make this a bit more specific in regards to not delete already published release notes?
33314ca to
ce06084
Compare
Promotes the release commit to master automatically once the release PR merges into dev. This is a manual step today. classify runs only for a merged v<X.Y.Z>-stage branch that parses as semver, so promote is skipped on unrelated merges into dev. It fails if that PR was not opened by amazon-ecs-bot, so a manually staged release stops here rather than promoting. promote checks the version is not already released, extracts the changelog section, verifies the release commit is reachable from dev, fast-forwards master, then drafts the release. Publishing the draft stays manual and creates the tag. The reachability check rejects a squash or rebase merge, which would otherwise leave master on a commit dev no longer contains. Requires a paired change to master's branch protection so the App can push. Until then promote fails at the push step, leaving master unmoved.
ce06084 to
9224c19
Compare
4 participants
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.classifyalso requires the release PR to have been opened byamazon-ecs-bot[bot], so only a PR thatcreate-release-prgenerated is promoted automatically. This one fails rather than skipping: a manually staged release is a real release, so it should be visible in the run list rather than silently doing nothing. The operator promotesmasterby hand in that case, which is the process today.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, extract that version'sCHANGELOG.mdsection, fast-forwardmasterto the release commit, then draft the release with that section as the body. Both checks run before the push, so a failed check leavesmasteruntouched. Publishing the draft stays manual, and is what creates thev<X.Y.Z>tag.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 - no release is 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. Forkdevwas reverted between cases so each ran from the same state.Happy path tested - merged the release PR as a merge commit:
masterfast-forwarded to the release commit, and the release was drafted with that version'sCHANGELOG.mdsection as its bodymasterondev's historyFailure paths tested - each stopped at its own check, with
masteruntouched and nothing drafted:Squash-merged the release PR
devand orphans the release commitRelease branch with no
# X.Y.Zsection inCHANGELOG.mdVersion that already had a
v<X.Y.Z>tag but no release objectRelease PR opened by an author other than the release bot
classify, beforepromotewas reached at allSkipped as intended: merging an unrelated PR into
dev, and closing a release PR without merging it.Description for the changelog
Housekeeping: add an action to automate merging release PRs to master.
Licensing
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.