fix(ci): rsync gh-pages publishes by checksum, not size+mtime - #372
Merged
Conversation
Deploy e99fa1d published NEW app chunk hashes with a STALE app/index.html (and 404.html + sw.js) still referencing the deleted old entry chunk — the live app kept loading pre-#366 code even after the deploy went green. Root cause: rsync's default quick check skips files whose size and mtime match. Both sides of this sync are freshly generated (cp'd build output vs a just-checked-out gh-pages worktree), so every mtime is "now" and carries no signal — and a rebuild substitutes 8-char content hashes for 8-char content hashes, so index.html/404.html/sw.js keep the exact same byte size across builds. When the prepare-copy and the worktree checkout landed in the same second, the quick check silently skipped precisely the three files whose size never changes. Every earlier deploy dodged this by a one-second timing margin. --checksum makes the decision by content, deterministically. git add -A already dedupes genuinely unchanged files, so the only cost is reading both trees. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Signed-off-by: xNet Test <test@xnet.dev>
Contributor
|
Preview removed for PR #372. |
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.
The second deploy-pipeline bug (stacked on #370)
After #370 unblocked Deploy Site, run
28709576907went green — but the live app still served pre-#366 code. The publish commit (e99fa1de) tells the story: all the chunk renames landed (index-DppD45_e.js → index-BuveDUTb.js,web-worker-BIYC6Nw7.js → web-worker-BFqMZy2X.js, …) butapp/index.html,app/404.html, andapp/sw.jsare absent from the diffstat — gh-pages ended up with a staleindex.htmlpointing at a deleted entry chunk.Root cause
publish-gh-pagessyncs withrsync -a, whose quick check skips files whose size and mtime both match:index.html/404.html/sw.jsare byte-for-byte the same length across builds.cp -Rbuild output (prepare step) vs a just-git worktree add-ed checkout (publish step) — every mtime is "now". This run's prepare-copy and checkout landed in the same second, so the quick check called them identical.Every prior deploy dodged this by a one-second timing margin; it's a latent race in every publish (production, PR previews, branch previews — all use this action).
Fix
rsync -a --checksum— decide by content, deterministically.git add -Aalready ignores genuinely unchanged files, so the only cost is reading both trees.After merge
.github/**isn't in Deploy Site's path filters, so I'llworkflow_dispatcha production deploy, then verifygh-pages:app/index.htmlreferences the live entry chunk and the deployed bundle carries the #366/#369 markers.🤖 Generated with Claude Code