feat(docker): allow overriding the image org with DDEV_DOCKER_ORG - #54
Merged
Conversation
ddev#8753 [skip buildkite] `DDEV_DOCKER_ORG` points a `ddev` binary at a different Docker Hub organization for DDEV's own images, so a release built somewhere other than `ddev/ddev` can be pull-tested. Unset, which is every normal build, nothing changes. - Fixes ddev#8753 `versionconstants.go` hardcodes the `ddev/` org, but the image workflows resolve `DOCKER_ORG` to `ddevhq` for `ddev-test/ddev`. A binary built there asks for `ddev/ddev-webserver:vX.Y.Z` while its images went to `ddevhq`, so `ddev start` fails with `manifest unknown` and the release cannot be tested end to end. An unexported `imageRepo()` in `pkg/docker/images.go` swaps the org on the five images DDEV pulls for itself: web (including `-prod`), db, ssh-agent, router, and xhgui. `postgres` comes from upstream, has no org, and is returned unchanged. With the variable unset `imageRepo()` returns its input, so there is no new behavior for anyone not setting it. ```bash ddev version -j | jq -r '.raw.web' # ddev/ddev-webserver:<tag> for i in ddev-webserver ddev-traefik-router ddev-ssh-agent; do docker tag ddev/$i:<tag> myorg/$i:<tag> done DDEV_DOCKER_ORG=myorg ddev poweroff && DDEV_DOCKER_ORG=myorg ddev start docker ps --format '{{.Names}}\t{{.Image}}' # every ddev image under myorg/ ``` `ddev version` reports the resolved references, so it also shows the override without starting anything. `TestImageRepoDockerOrg` in `pkg/docker/images_test.go` covers the default, the override across all five getters, `postgres` being left alone, and an empty value falling back to `ddev`. No behavior change unless `DDEV_DOCKER_ORG` is set. Documented under release-management.md next to the `ddev-test/ddev` setup notes, since pull-testing a release built there is what it exists for. Known gaps, all left alone deliberately: `ddev/ddev-utilities` is not redirected, `ddev delete images` does not discover images pulled under the override org, and add-ons and other extra services keep naming their own images, since those come from the add-on's `docker-compose.*.yaml` rather than from here. None of them block pull-testing a release. Co-Authored-By: Claude Opus 5 (1M context) <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.
…
make release-prep TAG=v1.25.4-rc1now works: the images are published underthat exact tag and the binary built from it pulls them, while
lateststays onthe last stable release.
release-prep.shandrelease-marker.shaccepted onlyvX.Y.Z, so aprerelease could not be stamped at all. Underneath that,
image-build-push.ymladded-t latestunconditionally alongside the releasetag, which is why release-management.md told you not to run
release-prepfora prerelease: the images would have been correct, but
latestwould havefollowed an rc.
Two questions were tangled together behind the same
^vX\.Y\.Z$regex, andthey want different answers:
-alpha/-beta/-rcin thethree places that ask:
pkg/docker/images.go,release-prep.sh, andrelease-marker.sh. Naming the kinds rather than accepting any suffix iswhat keeps
git describe'sv1.25.4-15-gabcdef1and-dirtyforms frombeing stamped as a release by accident.
latest? Onlyimage-build-push.ymlwas wrong here, andit needs no regex:
release-marker.shhas already vetted the shape, so a-in the tag means prerelease.
Resolving to the release tag at all is about what people see —
ddev versionand
docker imagesnamev1.25.4-rc1instead of a content hash nobodyrecognizes — so a prerelease wants the same treatment a stable release gets.
Deliberately unchanged:
validate-image-tag.sh's rejection of release-shapedcontent tags (a branch named
v1.25.4-rc1would publish...:v1.25.4-rc1-<hash>, a different string that can't shadow a realprerelease image); the
push-tagged-*.ymlvalidation escape hatches, so amanual dispatch still can't hand-push a prerelease tag; and the
latestgatesin
containers_shared.mkandbuild_image.sh, which are already stable-onlyand sit in image hash paths, where an edit would force every image to be
rebuilt and republished for no behavior change.
Then reset with
git checkout ..TestResolveImageTagcovers the accepted prerelease kinds plus-dirtyand anunrecognized suffix falling back to the content hash.
release_prep_test.shasserts a prerelease stamps and reads back like a release, and its
rejected-tags list now carries the
git describeshapes.latestis not covered by either, since it only happens insideimage-build-push.yml.No change to a stable release. Worth cutting one prerelease with this in place
before relying on it, since the
latestbehavior can only be observed in areal workflow run.
Co-Authored-By: Claude Opus 5 (1M context) noreply@anthropic.com<!--
PR titles have very precise rules, please read
https://docs.ddev.com/en/stable/developers/building-contributing/#pull-request-title-guidelines
If this is a nontrivial contribution, please create an issue for discussion first, or discuss it first in Discord, https://ddev.com/s/discord. This will save you time and help direct the feature.
-->
Short Summary (TL;DR)
The Issue
How This PR Solves The Issue
Manual Testing Instructions
Automated Testing Overview
Release/Deployment Notes