Pull MinIO from a registry that still serves it

[dimitri-yatsenko]

The Development workflow — the docs site deploy — has failed on every push to main since MinIO withdrew its public images. Today's three merges all show it red:

minio Error pull access denied for minio/minio, repository does not exist
or may require 'docker login': denied

minio/minio on Docker Hub is gone entirely — any tag, not just latest — and quay.io/minio/minio now requires authentication. Chainguard publishes a maintained build that needs no credentials and is drop-in here. It ships mc, so the mc ready local healthcheck is unchanged, and it is already what datajoint-python's test fixture uses (datajoint/datajoint-python#1559).

Overridable through MINIO_IMAGE so a deployment can point at its own mirror without editing the file.

Verification

Ran what CI runs, end to end:

MODE=BUILD DJ_PYTHON_PATH=../datajoint-python docker compose up --exit-code-from docs --build

MinIO healthy in about ten seconds, Documentation built in 9.82 seconds, every container exited 0.

One local-only wrinkle, documented in the file

The image runs as nonroot (uid 65532). A minio_data volume left behind by the old root-owned image is not writable by it, and MinIO exits with "Unable to write to the backend". A fresh volume inherits the image's world-writable /data and is fine, so docker compose down -v clears it once. CI runners start clean and never see this — I hit it locally and it cost a confusing build, which is why the comment is in the file rather than only here.

Worth a follow-up, not done here

In MODE=BUILD the docs service only runs pip install, gen_llms_full.py and mkdocs build — it never touches MySQL, PostgreSQL or MinIO. But depends_on makes all three start and go healthy first, which is why a registry outage took down the docs deploy at all. Putting the three behind a compose profile would make BUILD and LIVE independent of them. Out of scope for a red-CI fix.