Repository navigation
fix(website): deploy main, not the tag ref - #837
chappie-daemon wants to merge 2 commits into
Conversation
Two fixes to the release-triggered deploy observed in run 38835604913: 1. The website environment's custom branch policy does not admit tag refs, and the release event's ref IS a tag — the deploy can never pass environment protection. Checkout refs/heads/main instead: the release commit is main's tip by construction (changesets opens the release PR from main), so the deployed build is the released content. 2. Restore job-level concurrency (lost when the workflow landed on main without it): a relay release must fail the job's tag filter before it enters the deploy queue, not after, or it can replace a queued website deploy.
|
 [High impact] Changes deployment workflow to always deploy from main branch. Do not merge yet: release deploys remain blocked, and checkout can select code outside the release. Findings
|
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| with: | ||
| ref: refs/heads/main |
There was a problem hiding this comment.
If the website environment rejects release tags as described, checking out main will not unblock it. GitHub checks the triggering tag against the environment policy before running any steps. actions/checkout cannot change that event ref, so the job still fails before checkout runs. Allow website release tags in the environment policy, or start a separate deployment run on main.
| - name: Checkout | ||
| uses: actions/checkout@v3 | ||
| with: | ||
| ref: refs/heads/main |
There was a problem hiding this comment.
If another PR merges while a deploy waits, or someone manually deploys an older release after main advances, this checkout builds current main instead of the released commit. The live website can then include changes outside the published release. Changesets publishing from main does not keep that branch fixed afterward. Keep the build tied to the release tag or commit, even if the deployment run must start on main.
Greptile P1 on #838: the release-trigger move dropped main's old workflow_dispatch guard, so a manual run from any branch would build the selected ref and wrangler-deploy it to production. Restore the guard: dispatch requires github.ref == refs/heads/main; release runs are unaffected (their ref is the website tag, admitted by the tag_name check). Coordinated with #837, which pins the release checkout to refs/heads/main for the environment's branch policy.
This branch has not been deployed
2 participants
Fixes the failure in run 38835604913 — "Tag nostream-website@1.1.1 is not allowed to deploy to website due to environment protection rules".
Cause: the
websiteenvironment uses a custom branch policy, and GitHub's deployment protection only matches branch names — a tag ref (refs/tags/nostream-website@1.1.1, which is what arelease: publishedtrigger carries) can never pass it. Every website release would fail the same way.Fix 1 — deploy main: the checkout pins
refs/heads/main. The release commit is main's tip by construction (changesets opens the release PR from main and merging it publishes the release), so the deployed build is exactly the released content.Fix 2 — job-level concurrency restored: main's copy of the workflow carries the concurrency block at workflow level (it landed without the round-1 review fix from #834). At workflow level a relay release (
v*tag) enters the deploy queue before the job's tag filter rejects it, and as a queued entry it can replace a pending website deploy. Moved back into the job with its rationale comment.To deploy nostream-website@1.1.1 after merge: re-run 38835604913 (or trigger workflow_dispatch on main).