fix: stale-pin check should compare against the resolved release tag, not the raw hash - #8801
Open
weitzman wants to merge 1 commit into
Open
Conversation
The stale-pin check added in ddev#8682 compared a pinned image's com.ddev.image-tag label against the raw content-hash WebTag/BaseDBTag constants, instead of docker.ResolveImageTag(tag, branch) - the same resolution GetWebImage()/GetDBImage() already use to compute what a default image actually is. On a release build, TagBranch is a vX.Y.Z tag and ResolveImageTag returns that readable tag instead of the hash, because that's the tag DDEV's own release automation bakes into the label of the official image it publishes (containers_shared.mk: DDEV_IMAGE_TAG defaults to VERSION). So on DDEV v1.25.4, a dbimage built FROM (and therefore inheriting the label of) the official ddev/ddev-dbserver-mysql-8.0:v1.25.4 image was reported as "built for DDEV images v1.25.4 but this DDEV expects 27b956a558" - a false positive on a pin that is in fact current, undermining exactly the warning ddev#8682 was meant to provide. ddev#8787 (merged 2026-09-01) already fixed the equivalent `ddev version` display path to go through docker.GetWebImage()/ResolveImageTag rather than the raw WebTag constant; this applies the same fix to the stale-pin check config_custom.go left behind. Found via meprofilesvc's dbimage-based CI, which pins the official v1.25.4 dbserver image, following v1.25.4's release.
|
Download this PR's build for your OS and architecture with: ddev utility download-ddev --pr 8801Or download the artifact for your OS and architecture directly:
See Testing a PR.
|
Member
|
Shucks, sorry to miss this! |
Member
|
Workaround for this problem until this goes into a release using build-and-push-seeded-image.sh example:
|
Member
|
I manually tested this with randyfay/mysql-97-tagbase:v1.25.4, built from v1.25.4, and it worked fine, no warning. |
rfay
approved these changes
Sep 3, 2026
rfay
left a comment
rfay
left a comment
Member
There was a problem hiding this comment.
Works great; really only touches CheckCustomConfig(), which is pretty safe anyway. Thanks! Sorry to have missed this.
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
2 participants
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.
Short Summary (TL;DR)
A pinned
webimage/dbimagebuilt from the official release image is reported stale even when it's current, because the check compares its label against the raw content-hashWebTag/BaseDBTagconstant instead of the resolved release tag those same constants otherwise resolve to.The Issue
The stale-pin warning added in #8682 (
imageVersionMismatch) reads a pinned image'scom.ddev.image-taglabel and compares it toversionconstants.WebTag/BaseDBTagdirectly. Those are the raw content-hash autotag values (e.g.27b956a558), not what a released DDEV actually expects.On a release build,
WebTagBranch/BaseDBTagBranchis avX.Y.Ztag, and the official image DDEV publishes for that release is labeled with that readable tag (containers_shared.mk:DDEV_IMAGE_TAGdefaults toVERSION, e.g.v1.25.4) - not the hash. So on DDEV v1.25.4, adbimagebuiltFROM ddev/ddev-dbserver-mysql-8.0:v1.25.4(and therefore inheriting that image'sv1.25.4label) is reported as:...even though the pin is exactly current. This defeats the purpose of the warning for anyone who follows the documented pattern of building a derived image FROM DDEV's official one.
Found via a project pinning the official
ddev/ddev-dbserver-mysql-8.0:v1.25.4as itsdbimagebase, immediately after v1.25.4's release.How This PR Solves The Issue
docker.GetWebImage()/docker.GetDBImage()already resolve the default image tag correctly viadocker.ResolveImageTag(tag, branch), which returns the branch when it's a release tag and the hash otherwise.imageVersionMismatch's two call sites inconfig_custom.gonow compute theirexpectedTagthe same way, instead of passing the raw constant.This mirrors #8787 (merged 2026-09-01), which fixed the equivalent
ddev versiondisplay path (TestCmdVersion) to go throughdocker.GetWebImage()/ResolveImageTagrather than the rawWebTagconstant - the stale-pin check was the one place this pattern was missed.Manual Testing Instructions
Automated Testing Overview
TestCheckCustomConfigDBImageReleaseTag(new,pkg/ddevapp/config_custom_test.go): temporarily setsBaseDBTag/BaseDBTagBranchto simulate a release build, builds a local image labeled with the resolved release tag, and assertsCheckCustomConfigreports no staleness note. Runs in-process (not through theddevbinary as a subprocess) since it needs to observe the mutatedversionconstantsvalues.TestUtilityCheckCustomConfigCmd/"dbimage built for a different DDEV version"(existing) updated to compare againstdocker.ResolveImageTag(...)instead of the raw constant, so it stays correct if this ever runs against a release-tagged test binary; behavior is unchanged for the normal (branch-tagged) CI case.Release/Deployment Notes
None - this only removes a false positive from an existing check; the check still correctly flags an image genuinely built for a different DDEV image generation (covered by the existing test).