Repository navigation
fix(deploy): run minio-init on the pinned MinIO image instead of pulling minio/mc - #197
Merged
Merged
Conversation
…ing minio/mc The deploy host cannot pull minio/mc (MinIO serves no images anonymously from Docker Hub any more), so every `docker compose up` since v2.37.0 aborted on the minio-init one-shot. The digest-pinned minio/minio image already ships the mc client at the same release, and the deploy host already has that image cached, so minio-init now runs on it. Docs, IMAGES.md and the spec's s49 passages follow. Infra/doc-only: no APP_VERSION bump, no changelog entry. Co-Authored-By: Claude Fable 5.1 <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
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.
Problem
The Jenkins deploy (
docker compose up --build -don the deploy host) fails since v2.37.0 (#192):#192 added the one-shot
minio-initservice on a second MinIO image,minio/mc. MinIO no longer serves its images anonymously from Docker Hub (already recorded indeploy/IMAGES.md). The deploy host only kept working becauseminio/miniowas cached from an earlier deploy —minio/mcwas never pulled there, so the first deploy after #192 aborts before any other image finishes.Fix
minio-initnow runs on the same digest-pinnedminio/minioimage as theminioservice. That image ships themcclient at/usr/bin/mc— at exactly the release the droppedminio/mcpin targeted (mc RELEASE.2025-08-13T08-35-41Zinsideminio RELEASE.2025-09-07T16-13-09Z). The entrypoint override and the bootstrap script are unchanged, so the deploy host needs no new pull at all. CI's e2e stack already relies on the same thing (docker exec <minio> mc …inci/e2e-shard.sh), as does theminiohealthcheck (mc ready local).deploy/docker-compose.yml—minio-initimage → the pinnedminio/minio; comment explains why.deploy/IMAGES.md— drop theminio/mcrow; MinIO note covers the single-image choice.deployment_manual.md— local-dev bucket snippet usesminio/minioinstead ofminio/mc.SKILLY_SPEC.md§49 — the two passages that said themcimage is pinned now say the bootstrap runs on the MinIO image.Infra/doc-only, no app behaviour change → no
APP_VERSIONbump, no changelog entry.Verification
docker compose -f deploy/docker-compose.yml configvalidates;minio-init.imagerenders to the pinnedminio/minio.minio-initscript onminio/minio(same digest) against a throwaway MinIO: first run creates bucket + policy + user and attaches the policy; second run is idempotent (policy … already attached); the scoped account lists the bucket.Caveat: the deploy host still depends on its cached
minio/miniolayer. A fresh host or a MinIO bump needs the internal mirrordeploy/IMAGES.mdprescribes.🤖 Generated with Claude Code