ci: build the deployed site the same way CI verifies it - #324
Merged
Conversation
Mirrors e-minguez/rke2-versions so both repos are configured identically. The deploy went through enriikke/gatsby-gh-pages-action@v2, which runs `npm install` (not `npm ci`) with whatever Node happens to be on the runner PATH. CI validated the lockfile on every PR and the deploy then ignored it, so a green gate did not actually guarantee the published site was built from the tree that passed. Build explicitly instead: pin Node to 24 to match ci.yaml, npm ci against the committed lockfile, and gatsby build --prefix-paths. Publish with the first-party Pages actions rather than pushing to a gh-pages branch; configure-pages switches the Pages source over on the first successful run, so there is no window where nothing is served. Bump msgpackr to 1.12.1 within lmdb's existing range so Node 24 works at all: 1.10.1 calls Buffer.utf8Write in a way Node 24 rejects, crashing gatsby build in Gatsby's lmdb datastore. Verified locally on Node 25. Also align setup-python to v7 and add .github/workflows/main.yaml to the frontend path filters, so a change to the deploy path rebuilds the site. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011hJ7bUefyiu9bjVZ914Kz4
The previous commit regenerated package-lock.json with Node 25's npm, which resolves the @emnapi optional dependencies differently. npm ci then failed on CI under Node 24 with "Missing: @emnapi/core@1.11.3 from lock file". Regenerate under Node 24.20.0 / npm 11.19.0 to match the version CI runs. Verified there: npm ci succeeds and gatsby build completes. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011hJ7bUefyiu9bjVZ914Kz4
Matches rke2-versions. configure-pages leaves the Pages source alone unless enablement is set. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011hJ7bUefyiu9bjVZ914Kz4
Closed
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.
Mirrors rke2-versions#242 so both repos are configured identically.
The problem
The deploy ran through
enriikke/gatsby-gh-pages-action@v2, which runsnpm install, notnpm ci(await i.exec(\${u} install`, [], { cwd: r })), re-resolving dependencies and ignoring the committed lockfile — using whatever Node was on the runner PATH, since the deploy job never ransetup-node. CI validates the lockfile on every PR and the deploy then ignored it, so a greenci-okdid not guarantee the published site was built from the tree that passed. The action is unmaintained and still declares the retirednode16` runtime.The fix
setup-nodepinned to 24, matchingci.yamlnpm ciagainst the committed lockfilenpm run build -- --prefix-paths, same args as beforeconfigure-pagesflips the Pages source on the first successful run, so the existinggh-pagescontent keeps serving until the new deploy succeedsNo in-repo
CNAME(cname: null) — the custom domain is inherited from the user-level Pages site and is unaffected.msgpackr bump
Node 24 could not work here at all before this: the lockfile pinned
msgpackr1.10.1, which callsBuffer.utf8Writein a way Node 24 rejects, crashinggatsby buildinside Gatsby's lmdb datastore. Bumped to 1.12.1, which stays inside the^1.5.4rangelmdb2.5.3 already asks for — nopackage.jsonchange, lockfile only. This is the same versionlockFileMaintenancearrived at on its own in rke2-versions.Verified locally on Node 25: build completes.
Also
setup-pythonaligned to v7, matching rke2-versions (supersedes Update actions/setup-python action to v7 - autoclosed #299)..github/workflows/main.yamladded to the frontend path filters, so a change to the deploy path rebuilds the site rather than merging on a trivially-greenci-ok.🤖 Generated with Claude Code
https://claude.ai/code/session_011hJ7bUefyiu9bjVZ914Kz4