fix: Make netlify-fetch immune to stale cached release branches - #905
Open
lfrancke wants to merge 2 commits into
Open
fix: Make netlify-fetch immune to stale cached release branches#905lfrancke wants to merge 2 commits into
lfrancke wants to merge 2 commits into
Conversation
✅ Deploy Preview for stackable-docs ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
NickLarsenNZ
previously approved these changes
Jul 28, 2026
NickLarsenNZ
left a comment
Member
There was a problem hiding this comment.
Left a comment, but in any case, it's an improvement.
Production builds failed with antora unable to find object e9b0f5d on release-26.7. That object is the ui/NOTICE blob: release-26.7 is the first release branch cut after the UI was vendored into this repo, so ui/ is regular content there instead of a submodule gitlink - and the blob-materializing loop excluded ui/ from its pathspec checkouts, a rule written when every release branch still had the submodule. Antora reads the whole tree of a content branch with isomorphic-git, which cannot fetch missing objects on demand, and died on the first ui blob. Reproduced and verified against a fresh blobless clone: with the exclusion the exact production error appears, without it the build passes and no tip objects are missing. Dropping the exclusion is harmless for the old branches: a gitlink has no blobs to fetch. Additional hardening while in here: - branch list from git ls-remote instead of the cached remote-tracking refs (make expanded the old list before the fetch even ran, so a brand-new release branch was invisible to its first build) - no more silent failures: set -e and no -q on fetch abort the build at the failing command instead of surfacing later as a confusing antora error - gc.auto=0 inside the loop and git fetch --all --prune keep the long-lived netlify build cache tidy and race-free
lfrancke
force-pushed
the
fix/netlify-fetch-stale-refs
branch
from
July 28, 2026 15:55
83186f8 to
5dc9fe0
Compare
Review feedback (set -e at the top / pipefail): make runs every recipe line in its own shell, so a leading set -e would only govern itself, and the shell is sh, which has no pipefail - but the spirit of the comment found a real gap: a failing ls-remote inside the command substitution would have silently emptied the loop. The list is now captured and checked explicitly, and set -eu replaces set -e.
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
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.
Description
Production docs builds fail with
FATAL (antora): Could not find e9b0f5de... (branch: release-26.7).Root cause
e9b0f5de is not a commit, it is a blob:
ui/NOTICEon release-26.7.And it could not be found because (see the fix section below) we excluded
uifrom checkout because it used to be a submodule. And theisomorphic-gitused by Antora can't dynamically fetch missing content so.... it was missing.The fix
Do not exclude UI anymore... simple as that :(
Separate preemptive fixes/hardening
These were "discovered" during the research...would not really help the root cause but good to have anyway.
gc.auto=0for the loop commands, so background gc cannot race the ref updates.set -e+ no-qon fetch: to just fail where the failure actually happens to get a better error messagegit fetch --all --pruneto delete stale stuff from the cache, not only add or updateThe first build after a new release branch can also fail because the branch list that is used uses the last cached git state from the previous run. That doesn't have the new release branch so it can fail. This now uses
git ls-remote --heads origin(instead ofgit branch -r) to make sure we have the up-to-date state.Verified by simulation (by Claude): blobless clone (like netlify's), stale
release-26.7ref planted pointing at an outdated commit,make netlify-fetchrun - the ref force-updates to the real remote tip, all content blobs of every release tip are present (only the deliberately excludedui/blobs stay missing, which antora never reads), working tree clean, exit 0.