ci(pages): wait for releases/latest before deploying on a release publish#187
Merged
Conversation
…lish The release:published event fires the Pages deploy seconds before GitHub recomputes which release is 'latest', so the build resolved the previous tag and shipped stale version + download links (observed on v0.4.36: the auto- deploy ran 6s after publish and shipped v0.4.35; a manual redeploy fixed it). The cache-busting in site/src/lib/version.ts defeats CDN staleness but not this server-side propagation lag. Gate the build on releases/latest reporting the just-published tag (poll ~5 min, then fail rather than ship stale). Only for non-prereleases: the landing page tracks the latest stable release, which never reports a prerelease, so gating a beta publish on it would spin until timeout. push / workflow_dispatch runs have no tag to wait for and skip the gate.
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.
Problem
The
release: publishedevent triggers the Pages deploy seconds before GitHub recomputes which release is "latest". The build resolvesreleases/latest, gets the previous tag, and ships stale version + download links.Observed live on v0.4.36: the auto-deploy ran 6s after publish and shipped v0.4.35 (wordmark +
.dmg/-setup.exelinks all pointed at 0.4.35). A manual redeploy once the API had propagated fixed it.The existing cache-busting in
site/src/lib/version.ts(no-cache headers + per-build_cbquery) defeats CDN staleness, but this is server-side propagation lag — a freshly-revalidated body still names the old release until GitHub finishes recomputinglatest.Fix
Add a gate step to
deploy-pages.yml: when a release publish triggers the run, pollreleases/latest(cache-busted, ~5 min budget) until it reports the just-publishedtag_namebefore building. If it never catches up, fail rather than ship a stale site — re-running the job once the API recovers is the recovery path.Scoped to
github.event_name == 'release' && release.prerelease == false:resolveLatestRelease→releases/latest), which never reports a prerelease — so gating a beta publish on it would spin until timeout. Betas skip the gate.push/workflow_dispatchruns have no specific tag to wait for and skip it too.Validation
actionlintclean; YAML parses.