fix(images): build against the resolved version, not latest - #108
Merged
Conversation
Eight Dockerfiles fetched "latest" themselves while the merge job separately resolved "latest" to compute the tag. Two resolutions, minutes apart, with nothing tying them together: an upstream release landing between them tags an image with a version it does not contain. bendwyer/github-workflows#194 now resolves once and passes VERSION as a build-arg. These consume it, so the artifact and its tag come from the same value. The six that download a GitHub release asset move from releases/latest to releases/download/v${VERSION}, since every one of these upstreams tags vX.Y.Z and get-version.sh already strips the v. The two npm images pin the package spec instead. flux-mcp, paperless-mcp and terraform-mcp no longer need jq, having stopped querying the API themselves. Verified all eight build against their resolved version, that the installed version matches the arg rather than latest (ansible-mcp 26.6.0, context7-mcp 4.0.5, terraform-mcp 1.3.0), and that a wrong VERSION now fails the build instead of silently falling back. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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.
Why
Eight Dockerfiles fetched
latestthemselves during the build, while themergejob separately resolvedlatestto compute the tag. Two resolutions, minutes apart, with nothing tying them together — so an upstream release landing between them tags an image with a version it does not contain.bendwyer/github-workflows#194, already merged, resolves each version once in the
changesjob and passes it as aVERSIONbuild-arg. This consumes it, so the artifact and its tag come from the same value.What
The six that download a GitHub release asset move from
releases/latest/download/toreleases/download/v${VERSION}/. Every one of these upstreams tagsvX.Y.Zandget-version.shalready strips thev, sov${VERSION}reconstructs the tag exactly — verified against all six before rewriting the URLs.The two npm images pin the package spec instead:
npm install <pkg>@${VERSION}.flux-mcp,paperless-mcpandterraform-mcpalso dropjq, since they no longer query the API themselves.Untouched:
comictagger(already derives its tag from the pip pin, #106),kobo-book-downloader(#107), and the four first-party images whose version is a literal.Verification
All eight build against their resolved version:
The installed version matches the arg rather than latest —
ansible-mcpreports 26.6.0,context7-mcp4.0.5,terraform-mcp1.3.0 from its own--version.And the pin is load-bearing:
--build-arg VERSION=99.99.99fails the build forterraform-mcpandgithub-mcprather than falling back to latest. Without that check this change would look correct while doing nothing.humble-cli --versionprintsdev, which is upstream's own build stamp, so that one is confirmed by the download URL rather than by the binary.Note
The four first-party images now receive a
VERSIONbuild-arg they do not consume, which logs an unconsumed build-arg warning. Harmless, and preferable to adding a no-opARGto each just to silence it.🤖 Generated with Claude Code