BE-608: pin MinIO client image and gate bucket init on health - #9241
BE-608: pin MinIO client image and gate bucket init on health#9241claude[bot] wants to merge 3 commits into
Conversation
Pin the MinIO client image to minio/mc:RELEASE.2025-08-13T08-35-41Z. It was previously untagged, so every developer pulled whatever client release was newest that day and an upstream CLI change could break local setup with no commit to point at. Add a healthcheck to the minio service against /minio/health/live and switch the bucket initialiser from the short-form depends_on list to condition: service_healthy. The short form waits only for the container to start, not for MinIO to accept connections, so the initialiser could race it, fail with connection refused, and never create the uploads bucket.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
3 Skipped Deployments
|
github-actions
Bot
added
the
area/infra
PR SummaryLow Risk Overview The MinIO server moves from an unpinned The Reviewed by Cursor Bugbot for commit 8a6ebe8. Bugbot is set up for automated code reviews on this repo. Configure here. |
The client image was pinned by tag alone. A tag is mutable, so it does not actually guarantee every developer resolves the same image. Add the `sha256:` manifest digest alongside the existing tag, keeping the tag for readability. The digest resolves to the multi-arch manifest list (linux/amd64, linux/arm64, linux/ppc64le). `RELEASE.2025-08-13T08-35-41Z` is confirmed still correct: enumerating all 473 tags on Docker Hub `minio/mc` shows it is the newest of the 471 `RELEASE.*` tags and the target of `latest`. There is no semver series to prefer instead — the only non-release tags are `latest` and `edge`, so upstream's `RELEASE.<timestamp>Z` is its version scheme. The tag is a year old because publishing stopped, not because it was picked carelessly: `minio/mc`, `minio/minio` and `minio/operator` on Docker Hub all last received a push in Sept 2025. quay.io could not be reached from this environment to check for newer tags there, so the registry choice still wants a human eye; a comment records that.
|
Pushed The pin is now On the tag being a timestamp rather than a version number: that is upstream's scheme, not a choice made here. Enumerating all 473 tags on Docker Hub On why it is a year old: publishing stopped rather than the tag being stale by oversight. Generated by Claude Code |
The `minio` service pulled `quay.io/minio/minio` untagged, so every developer got whatever server release was newest that day — the other half of the pinning gap this PR set out to close. Pin it to `RELEASE.2025-09-07T16-13-09Z`, the newest release and the one `latest` points at (verified on Docker Hub: the tag resolves, and the linux/amd64 child of its manifest list is a1a8bd4, matching upstream's published digest for that release). Pinned by tag alone rather than by digest: quay.io is unreachable from this environment's egress proxy, so its digest cannot be verified, and a Docker Hub digest is not valid for the quay copy of the same tag. The client stays on `RELEASE.2025-08-13T08-35-41Z`. `minio/minio` and `minio/mc` are separate repositories with independent release-timestamp series, and `minio/mc:RELEASE.2025-09-07T16-13-09Z` does not exist — 404 from both the registry manifest API and the Hub tag API. mc's newest of its 473 tags is the one already pinned here, which `latest` also points at. The two images cannot share a version string. Also trims the client's comment, which had grown to six lines.
|
Pinned the server to The client can't share that version, though: Generated by Claude Code |
2 participants
Requested by Ciaran Morinan · Slack thread
🌟 What is the purpose of this PR?
Fixes two bugs in the MinIO bucket initialiser in
infra/compose/compose.ymlthat make local setup fail intermittently and unpredictably.Before. The MinIO bucket initialiser used an untagged
minio/mcimage, so every developer pulled whatever client release was newest that day and an upstream CLI change could break local setup with no commit to point at. It also declared its dependency on MinIO with Compose's short-form list, which waits only for the MinIO container to start, not for MinIO to accept connections. The init script made a single unretried attempt and was set never to restart, so losing that race meant it died withconnection refusedand the uploads bucket was never created.After. The client image is pinned to a specific verified release. MinIO has a healthcheck against its documented
/minio/health/liveendpoint, and the initialiser waits forcondition: service_healthy, so it does not run until MinIO is serving. The race is fixed by ordering rather than asleep.How.
minio/mcis pinned tominio/mc:RELEASE.2025-08-13T08-35-41Z. Theminioservice gains a healthcheck polling/minio/health/liveevery 2s (2s timeout, 15 retries), andminio-ensure-bucket-existsswaps its short-formdepends_on: - miniofor the long form withcondition: service_healthy— matching the 23 other healthcheck-gated dependencies already in this file.🔗 Related links
🚫 Blocked by
🔍 What does this change?
:latest) tominio/mc:RELEASE.2025-08-13T08-35-41Z.healthcheckto theminioservice againsthttp://localhost:9000/minio/health/live, written as a fallback chain (curl … || mc ready local).minio-ensure-bucket-existsfrom short-formdepends_onto the long form withcondition: service_healthy.Pre-Merge Checklist 🚀
🚢 Has this modified a publishable library?
This PR:
📜 Does this require a change to the docs?
The changes in this PR:
🕸️ Does this require a change to the Turbo Graph?
The changes in this PR:
The healthcheck command is untested at runtime. Docker could not be run in this environment, so it is written as a fallback chain (
curl … || mc ready local) becausecurl's presence in the MinIO server image could not be confirmed — quay.io is blocked by the network proxy. Onedocker compose upon thedevprofile would close that out.🐾 Next steps
Two related gaps deliberately left out of scope:
quay.io/minio/miniois still untagged — the other half of the image-pinning gap.apiservice has no dependency onminio-ensure-bucket-exists, so it can still start before the uploads bucket exists.🛡 What tests cover this?
CMD-SHELLtest, the dependency as a long-form condition). The pinned tag was confirmed to exist against the registry API with an HTTP 200 manifest response.❓ How to test this?
devprofile with Compose from a clean state (no pre-existing MinIO volume).minio-ensure-bucket-existswaits forminioto report healthy, then exits 0, and that the uploads bucket exists afterwards.