ci(minio): pull the pinned MinIO images from quay.io now that Docker Hub's minio repos are gone

[BSalaeddin]

What

Repoint the two pinned MinIO images used by the e2e gate from Docker Hub to
quay.io. The digests are unchanged — only the registry host moves — so the
upload-validation gate still runs the exact images it was verified against.

image	before	after	digest
MinIO server	minio/minio	quay.io/minio/minio	sha256:14cea493…8936e (unchanged)
MinIO client	minio/mc	quay.io/minio/mc	sha256:a7fe349e…11727 (unchanged)

The MinIO docs guide's docker run line moves with it, so a reader copy-pasting
it does not hit the same wall.

Why

MinIO removed both repositories from Docker Hub. Verified 2026-09-12:

GET https://hub.docker.com/v2/repositories/minio/minio/  -> 404
GET https://hub.docker.com/v2/repositories/minio/mc/     -> 404
GET https://registry-1.docker.io/v2/minio/minio/manifests/sha256:14cea493…
    -> 401 {"errors":[{"code":"UNAUTHORIZED","message":"authentication required"}]}

The same two digests are served by quay.io (anonymous pull, HTTP 200 on both
manifests), which is why this is a one-line-per-image host change and not a
version bump:

GET https://quay.io/v2/minio/minio/manifests/sha256:14cea493…  -> 200
GET https://quay.io/v2/minio/mc/manifests/sha256:a7fe349e…     -> 200

Impact today: the Cross-framework E2E (Playwright + MinIO) job cannot pull its
images, so every PR whose diff routes to that job is red on an infrastructure
fault, not on its own content. PRs #415 and #419 are currently red on that job
alone — all 17 other checks on both are green.

Verification done locally

Booted the real stack from this branch on Windows + Docker 28.3.2:

pnpm run e2e:minio:up        # validate-env OK, both containers created
curl -sf http://localhost:9100/minio/health/live   # healthy on the first poll
docker compose ps -a
  wt-upup-ci-minio-1        quay.io/minio/minio@sha256:14cea493…  running  0
  wt-upup-ci-minio-setup-1  quay.io/minio/mc@sha256:a7fe349e…     exited   0
pnpm run e2e:minio:down      # volume + network removed

mc completed its bucket/policy setup with 0 errors and 0 warnings; an
anonymous GET /upup-e2e/ returns 403, i.e. the bucket exists and is private as
the gate expects.

Repo gates run green on the branch: docs:links:check (403 links, 105 anchors,
8 redirect targets, 64 pages), docs:snippets:check, docs:snippets:coverage,
docs:api-sync:check, env:check, test:quality. The pre-push hook
(typecheck, lint --continue, knip) ran on push with the turbo cache
forced off.

What CI covers

scripts/ci/resolve-affected-tests.mjs routes a docker-compose.yml change to
both e2e and minio, and resolve-affected-tests.test.mjs pins that rule. So
this PR's own run boots MinIO through the changed compose file and exercises the
pull path it fixes — if quay.io did not serve these digests, this PR would be
the one that goes red.

Notes for reviewers

• Merging this first unblocks seo(landing): Organization/WebSite entity JSON-LD, AI-crawler robots allow-list, md-twin alternates, HSTS + cf-visitor https redirect #415 and perf(landing): fix mobile LCP and cut the marketing pages from 6.3 MB to 0.6 MB #419. Suggested order afterwards: seo(landing): Organization/WebSite entity JSON-LD, AI-crawler robots allow-list, md-twin alternates, HSTS + cf-visitor https redirect #415,
  seo(landing): serve the IndexNow key file #416, seo(landing): query-driven titles, H1s and descriptions for the framework pages, home and top storage guides #417, docs(landing): claim-integrity pass — truthful wording for parity, providers, Node version, privacy and README #418, then perf(landing): fix mobile LCP and cut the marketing pages from 6.3 MB to 0.6 MB #419 (it shares HomepageHero/page.tsx hunks with
  seo(landing): query-driven titles, H1s and descriptions for the framework pages, home and top storage guides #417 and docs(landing): claim-integrity pass — truthful wording for parity, providers, Node version, privacy and README #418 and will need a rebase).
• The bump recipe in the compose header now points at
  quay.io/minio/minio:latest, so the next digest refresh does not silently
  reintroduce the dead Hub repo.
• Fleet-wide: BioFlow pins the same two Docker Hub images in ci.yml,
  nightly.yml and its production root compose; the equivalent fix is
  DevinoSolutions/BioFlow#250. Any other repo pinning minio/minio or
  minio/mc has the same latent breakage.

Owner questions

• Do we want a Devino-side mirror (or a pull-through cache) for the images the
  gates depend on, so the next upstream registry removal is not a fleet-wide
  CI outage? This PR does not assume one.

[codesandbox]

Review or Edit in CodeSandbox

Open the branch in Web Editor • VS Code • Insiders

Open Preview