fix: follow GHCR pagination when fetching tags, not just the first page#31
Open
stigdreyer wants to merge 1 commit into
Open
fix: follow GHCR pagination when fetching tags, not just the first page#31stigdreyer wants to merge 1 commit into
stigdreyer wants to merge 1 commit into
Conversation
GHCR silently caps tags/list responses below whatever `n` is requested (observed: n=10000 request, 1000 tags actually returned, with a Link: rel="next" header pointing at the rest) — and fetch_tags() never followed it, so any image with more tags than that cap silently lost everything past the first page. Tags come back in lexicographic order, so the truncation isn't random: it's a full page of the earliest-sorting tags, then a hard stop. For ghcr.io/home-assistant/home-assistant (years of near-daily CalVer releases, thousands of tags), this meant "latest" resolved to 2023.3.6 while 2026.7.2 existed entirely unseen past the cutoff — an update-PR downgrading a live 2026.7.0 install by three years. Also hardens the Docker Hub path the same way (its JSON response's `next` field was likewise ignored) — same class of bug, not yet observed to bite in practice since that endpoint orders by last_updated rather than lexicographically, but the same silent- truncation risk applies to any image with enough tags. Verified against the real registries: home-assistant/home-assistant now correctly returns 2026.7.2 as latest (4327 tags fetched across pages, vs. 1000 before), and a single-page image (music-assistant/server) is unaffected.
stigdreyer
added a commit
to stigdreyer/ziganka-containers
that referenced
this pull request
Jul 17, 2026
The auto-update workflow's version check hit a GHCR pagination bug (fixed upstream: halos-org/shared-workflows#31) and proposed downgrading from the live-running 2026.7.0 to 2023.3.6 — a 3+ year regression, not an update. Corrected to the real latest release (home-assistant/core's actual latest GitHub release, confirmed present as a ghcr.io tag). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
stigdreyer
pushed a commit
to stigdreyer/ziganka-containers
that referenced
this pull request
Jul 17, 2026
Corrected the Home Assistant target to the actual latest release (2026.7.2) before merging — the automated PR had proposed a downgrade to 2023.3.6 due to a GHCR pagination bug in the update checker (fixed upstream: halos-org/shared-workflows#31).
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.
Summary
fetch_tags()'s GHCR branch requestsn=10000but never follows the registry'sLink: rel="next"pagination header — it just takes whatever the first response contains. GHCR silently caps the actual page size below the requestednfor tag-heavy images, so any image with more tags than that cap loses everything past the first page, with no error or warning.How this was found
check-image-updates.shproduced a PR against a downstream repo proposing to changeghcr.io/home-assistant/home-assistantfrom2026.7.0(the live-running version) to2023.3.6— a 3+ year downgrade masquerading as an "update".Confirmed directly against the registry:
Despite requesting
n=10000, GHCR returned exactly 1000 tags and aLinkheader pointing at the rest. Tags come back in lexicographic order, so this isn't a random subset — it's a full page of the earliest-sorting tags (up to2023.4.0b2) with a hard stop, and2026.xreleases exist entirely past that cutoff, unseen.Fix
Link: rel="next"in a loop until absent, accumulating tags across all pages.nextfield was ignored) — hardened the same way, though I haven't observed it bite in practice since that endpoint orders bylast_updatedrather than lexicographically. Same silent-truncation risk for any image with enough tags, though.Tested
Extracted
fetch_tags()and ran it directly against the real registries:ghcr.io/home-assistant/home-assistant: now returns 4327 tags (vs. 1000 before), correctly including2026.7.0,2026.7.1,2026.7.2homeassistant:2026.7.0as the "current" tag: now correctly computesLatest: 2026.7.2(previously would have computed2023.3.6, per the actual downstream PR this surfaced from)ghcr.io/music-assistant/server(small image, genuinely single page, noLinkheader): unaffected, no regression — loop terminates immediately as beforeDid not modify
tag_pattern()or thesort -Vcomparison logic — those were already correct; the only issue was the tag list being incomplete before it ever reached them.