fix(ci): pull MinIO from quay.io, not Docker Hub - #304
Merged
Merged
Conversation
This was referenced Sep 13, 2026
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
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.
🚨 This blocks every pull request in the repository, and therefore the 0.13.0 release.
What happened
docker.io/minio/miniohas been removed from Docker Hub.Every PR fails at the Start MinIO step of
Integration tests (testcontainers)and can never reach a mergeable state. I found it on the docs PR (#303) for this release.It is not a flake and not a rate limit
Established before changing anything:
minio/minio:latest(not just the pinned tag)hub.docker.com/v2/repositories/minio/minioA rate limit answers
toomanyrequests; a 404 on the repository endpoint is the repository not existing. PR #292 passed this same job earlier today, so it disappeared within hours.The fix
Both pin sites move to quay.io, MinIO's own registry:
The exact pinned tag exists there — I checked the tag list before assuming, and it is present alongside
…-cpuv1and…hotfix.…variants. So this is a host change only: same publisher, same release tag, same build. What the tests exercise does not change, which is the whole reason for preferring it over bumping to a newer release while CI is red.Two sites, because the workflow step and
s3_archive.rsare pinned as a pair and the file already said they "must move together". Both now also record why the registry is not Docker Hub, so the next person does not repoint it back.Verified, not assumed
That also confirms
testcontainers'GenericImage::newaccepts a registry-qualified image name — the one thing about this change that could have failed quietly.Note on the supply chain
This repoints a build input to a different registry, which is a supply-chain change and worth stating plainly rather than burying: it is the same publisher's own registry, carrying the same tag that was previously pulled from Docker Hub, and the pin stays exact. No version was bumped to get CI green.
Merge this first — #303 and the release cut are both blocked behind it.