ci: gate the release branch on deploy-test - #348
Open
laazyj wants to merge 2 commits into
Open
Conversation
Contributor
CoverageOverall line coverage: 99.34% across 23 package(s).
|
laazyj
force-pushed
the
ci/deploy-test-in-release-prepare
branch
from
July 27, 2026 17:11
3b64589 to
06ff5a0
Compare
Reverses the placement from edabf89, which put the deploy behind the tag and so behind the merge — feedback landed after the release decision was already made. Running it in release-prepare.yml was no better: a reusable workflow runs at the caller's ref, so it would have deployed main's HEAD, which is not the tree being released. deploy-test.yml now also triggers on `push: release/**`. That branch is the only ref holding exactly what ships, version bumps and CHANGELOG.md included, and release-prepare.yml pushes it with the PAT, so the deploy starts by itself the moment the release PR exists. The result lands as a check on that PR, next to CI, and the merge checklist gains a line for it. Required status checks cannot express this — they are configured per base branch, and requiring it on main would block every PR. Trigger rather than a wrapper workflow so sandbox-cleanup keeps listening to one workflow name; a second name is one nothing validates when it drifts. `environment:` gains the `|| 'sandbox'` fallback the concurrency group already had, since a push event carries no inputs. release-tag.yml goes back to a single tag job. Also corrects three places that still named release.yml as ci.yml's workflow_call caller, stale since the deploy left that workflow.
A push to release/** now deploys on its own, so the two settings that bound that blast radius belong in the setup guide rather than only in repo settings: the sandbox environment's deployment-branch list, which is what actually gates the AWS role, and a ruleset restricting who can create or move a release branch.
laazyj
force-pushed
the
ci/deploy-test-in-release-prepare
branch
from
July 29, 2026 07:11
9330c52 to
3fe5c65
Compare
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
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.
What & why
Follow-up to #345. Two placements were wrong for the same underlying reason — neither tested the tree being released:
release-tag.yml(ci: gate the release tag on deploy-test #345, onmain): the deploy runs after the release PR is merged, so feedback lands after the release decision.release-prepare.yml(this PR's first revision): a reusable workflow runs at the caller's ref, so it would have deployedmain's HEAD — a different tree from the release branch.deploy-test.ymlnow also triggers onpush: release/**. The release branch is the only ref holding exactly what ships, version bumps andCHANGELOG.mdincluded, andrelease-prepare.ymlpushes it with the PAT — so the deploy starts by itself the moment the release PR exists, and lands as a check on that PR next to CI.release-tag.ymlreverts to a singletagjob; theparsesplit in #345 existed only to protect the deploy it no longer owns.A trigger, not a wrapper workflow
The first draft of this was a 35-line
release-deploy-test.ymlthat did nothing butuses: ./.github/workflows/deploy-test.yml. Adding the trigger todeploy-test.ymldirectly is better:sandbox-cleanup.ymlkeys off top-level workflow names, and a second name is one more thing nothing validates when it drifts — rename the wrapper and teardown silently stops firing for the release path. Its listener list goes back to[Deploy Test], with a note about what to do ifdeploy-test.ymlis ever called as a reusable workflow again.That needs one fix:
environment:gains the|| 'sandbox'fallback the concurrency group already had, since apushevent carries noinputsand an empty environment binding would silently dropAWS_ROLE_ARN/AWS_REGION.Worth knowing
mainwould block every PR — it only ever runs onrelease/**. The PR body now lists it explicitly.RELEASE_PR_TOKENgains a third reason to exist. The branch push only triggers the gate because it is PAT-authenticated; underGITHUB_TOKENthe release PR would simply have no Deploy Test check. Documented alongside the other two.deploy-test.ymlfor the branch tip. On a freshly cut branch those are the same tree.docs/ci.mdnow says so rather than implying otherwise; arun-ciinput ondeploy-test.ymlwould remove it, but that is a separate change.ci.yml,coverage-comment.yml,docs/ci.md) that still namedrelease.ymlasci.yml'sworkflow_callcaller — stale since the deploy left that workflow.docs/ci.mdpipeline diagram is redrawn top-to-bottom with the trigger written on each edge; the old side-by-side layout was built for a linear chain and had edges landing on the wrong boxes.Verification
actionlintclean on all workflows;npm run verifypasses. The path is exercised by the next Release Prepare dispatch — the branch push should produce a Deploy Test run againstrelease/vX.Y.Z, visible in the PR's checks.Checklist
npm run verifypasses locally🤖 Generated with Claude Code