Repository navigation
CI hotfix: blobless clone for the full-history job (checkout stalls are upstream) - #507
Merged
Merged
Conversation
Checked today's knowledge against the bundle compaction (359KB -> 191KB) before adding: token layer, img-cropped mobileWidth params, blog-list traps, record-baselines and the GA browser-channel distinction all survived in CONCEPTS rather than only the log - the outcome the compaction wanted. One gap remained, in the section a cold session reads first for visual questions: design/ had no site-palette concept at all. house-visual-spec is in-post SVG artwork, cover-pipeline is covers, so 'what palette does the site use?' resolved to nothing there while the LIGHT decision sat in docs/adr/0003 and architecture/css-pipeline. design/site-palette.md carries the decision, the audience-shaped reasoning that predicts future calls (dark = products bought by developers; light = services bought on trust), the token table, and the three surfaces where dark stays DELIBERATE - so nobody later 'fixes' the blog covers or the vibe-code-rescue campaign page into light. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Three failures in one session (Unit Tests 10m x2, build 15m1s), all inside 'Fetching the repository' and ending 'The operation was canceled', all cleared by a plain re-run completing the same job in 2-3 min. ci-gates documented checkout being slow and the 15/25 timeout raise that followed; it lacked the distinction that decides the response - a cap cannot rescue a step that never progresses. Adds the rule plus the log check that distinguishes a stall from a genuine failure, so nobody re-runs red that deserved to stay red. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…eckout stalls Paul's hunch was right that the action was at fault, though not our version: actions/checkout#2441 - open since 2026-05-19, silent stalls of 15-25 min on EU runners killed by timeout-minutes. That is exactly our signature (three in one session: Unit Tests 10m x2, build 15m1s, all inside 'Fetching the repository', all cleared by a plain re-run in 2-3 min). Upstream and unfixable by us. What IS ours is how much we ask for. The pack is 1.70 GiB and content/ alone is 625 MB across 1,576 images. _hugo.yml must keep fetch-depth: 0 because enableGitInfo feeds .Lastmod into article:modified_time and schema dateModified - so it now also sets filter: blob:none, which keeps commits and trees in full and skips HISTORICAL blobs. Verified rather than assumed, since the whole point is that GitInfo must keep working: - bare blobless clone: 4.7 MB in 1.1s, against a 1.70 GiB pack (370x) - git log -1 -- content/blog/<post>/index.md still returns the correct commit date in 0.02s, with the clone still at 4.7 MB - zero blobs fetched Also corrects the OKF entry written earlier today, which said 'it's a hang, re-run it' without knowing why. ci-gates now carries the upstream cause, the confirm-before-re-running log check, and the honest limit: this is a mitigation, not a cure, and the real floor is 625 MB of images in git - an LFS/CDN decision, not a checkout flag. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Contributor
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
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.
Paul's hunch — "looks like there is a bug with the latest action upgrade" —
was right that the action is at fault, though not our version of it.
Root cause: upstream, open, not ours
actions/checkout#2441 —
open since 2026-05-19, silent stalls of 15–25 min on EU runners, killed
by
timeout-minutes. That is our signature exactly:Fetching the repositoryFetching the repositoryFetching the repositoryWe can't fix it. Raising the cap can't either — a timeout cannot rescue a
step that never progresses; it only makes each failure cost longer.
What we can fix: how much we ask for
This repo is a heavy ask — 1.70 GiB pack, and
content/alone is625 MB across 1,576 images that every job pulls regardless of depth.
_hugo.ymlmust keepfetch-depth: 0, becauseenableGitInfofeeds.Lastmodintoarticle:modified_timeand schemadateModified— real SEOsurface, not decoration. So it now also sets
filter: blob:none: commitsand trees in full, historical blobs skipped, working-tree blobs fetched once
at checkout.
Verified rather than assumed, since the whole point is that GitInfo must
keep working:
git log -1 -- content/blog/<post>/index.md→ correct commit date in0.02s, clone still 4.7 MB — zero blobs fetched
Also: corrects an entry I wrote earlier today
ci-gatessaid "it's a hang, re-run it" without knowing why. It now carriesthe upstream cause, the log check that distinguishes a stall from a genuine
failure (so nobody re-runs red that deserved to stay red), and the honest
limit: this is a mitigation, not a cure. The real floor is 625 MB of images
in git — an LFS/CDN decision, not a checkout flag.
Bundle + one workflow file.
bin/hugo-buildgreen; OKF conformant.🤖 Generated with Claude Code