Repository navigation
ci: serve reylo.dev from a release branch each release moves - #129
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub. 1 Skipped Deployment
|
There was a problem hiding this comment.
Important
A notes-only re-dispatch, or a re-run of finish, force-pushes release back to the tag and drops any docs fixes cherry-picked onto it since — which is exactly the workflow AGENTS.md now reco
8000
mmends.
Reviewed changes
I reviewed moving reylo.dev from deploying on every push to main to deploying from a release branch that each release moves.
finishmovesreleaseto the tagged commit: once npm serves every version, the tag step now also force-pushes the tag's commit (resolved throughls-remoteand fetched when the depth-1 checkout lacks it) torefs/heads/releasewith the deploy key.- Key file cleanup through
trap: the deploy key is now removed on any exit from the step, not only after a successful push. AGENTS.mddocs deploy rule: production docs come fromrelease, a push tomainbuilds a preview, and a docs fix that holds for the released version can be cherry-picked ontorelease.
claude-opus-5-5 ｜ 𝕏
There was a problem hiding this comment.
ℹ️ The earlier concern is fixed. One minor suggestion inline, about how a failed compare is handled.
Reviewed changes
I reviewed 4b09aa6, which stops the release step from moving release back when that branch already holds the tag.
- Compare before the forced push: the step now asks GitHub's compare API for
<tag>...releasewith the job token. If the answer isidenticalorahead,releaseis left as it is. Otherwise (behind,diverged, or the branch is missing) it is force-moved to the tag. This keeps docs fixes cherry-picked ontoreleasethrough a notes-only re-dispatch or a re-run offinish. - Step comment updated: the comment now says when the move is skipped, and why it uses the compare API instead of the shallow checkout.
claude-opus-5-5 ｜ 𝕏
There was a problem hiding this comment.
✅ No new issues found. The earlier concern about a failed compare is fixed.
Reviewed changes
I reviewed 5aad676, which changes how the release step decides that release is missing.
- Separate existence check:
git ls-remote --exit-code --heads origin releasenow decides whether the branch exists. Exit 2 is the only result that counts as missing. Any other non-zero exit stops the step with an::error::, and theEXITtrap still deletes the key file. - Compare with no fallback:
gh api .../compareruns only when the branch exists. It no longer has|| status=missing, so under the defaultbash -eshell a 5xx, a rate limit or a network error fails the step instead of force-movingrelease.
claude-opus-5-5 ｜ 𝕏
reylo.dev deployed from every push to
main, while npm moves only when a release is dispatched, so the docs could describe for days what no published version does. For three days after 0.5.0 they described Slonik support, ISO 8601 intervals and.try(), none of which npm served.The site will instead serve a
releasebranch, which each release moves:release.yml's finish job now pushes the release's tagged commit toreleasewith the deploy key, after npm serves every version, right after it pushes the tag. It follows the tag rather than the run's commit, because a dispatch that only rewrites a release's notes runs on amainthat may hold unreleased changes. The push is forced, since docs fixes cherry-picked ontoreleasebetween releases aren't ancestors of the next release commit, thoughmainholds them too. The key file now goes through an exit trap, so a failing command can't leave it on disk.AGENTS.mdsays how the docs deploy now. A docs change that holds for the released version can go live before the next release, by cherry-picking it ontorelease.Outside this PR, Vercel's production branch moves from
maintoreleaseonce the branch exists, and a ruleset keepsreleaseto fast-forwards for everyone but the deploy key. Pushes tomainkeep building previews.actionlintpasses, andzizmorreports the same single low finding as onmain.