Skip to content

fix(infra): pull MinIO from quay.io on a pinned tag, not Docker Hub - #1388

Open
marcelo-maciel wants to merge 2 commits into
fullstackhero:mainfrom
marcelo-maciel:fix/minio-image-registry
Open

fix(infra): pull MinIO from quay.io on a pinned tag, not Docker Hub#1388
marcelo-maciel wants to merge 2 commits into
fullstackhero:mainfrom
marcelo-maciel:fix/minio-image-registry

Conversation

@marcelo-maciel

@marcelo-maciel marcelo-maciel commented Sep 14, 2026

Copy link
Copy Markdown
Contributor

Problem

MinIO withdrew minio/minio from Docker Hub. The repository is gone (GET https://hub.docker.com/v2/repositories/minio/minio/ answers {"message": "object not found"}), and a pull fails:

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

Everything in the kit that boots MinIO is broken on main today, with no change of ours involved:

  • Integration tests. The Testcontainers harness starts a MinIO container per fixture, so container start throws and every test in the project fails. On the current main that is Failed: 724, Passed: 23 in Integration.Tests, plus Integration.Middleware.Tests.
  • The Aspire AppHost (dotnet run --project src/Host/FSH.Starter.AppHost), the documented way to run the whole stack.
  • The Docker Compose deployment under deploy/docker/.

Fix

The image is still published, at quay.io/minio/minio. The registry moves, and the tag is pinned:

File Change
src/Tests/Integration.Tests/Infrastructure/FshWebApplicationFactory.cs MinioBuilder("quay.io/minio/minio:RELEASE.2025-09-07T16-13-09Z")
src/Tests/Integration.Middleware.Tests/Infrastructure/MiddlewareWebApplicationFactory.cs same
src/Host/FSH.Starter.AppHost/AppHost.cs .WithImageRegistry("quay.io") + .WithImageTag(...)
deploy/docker/docker-compose.yml image: quay.io/minio/minio:RELEASE.2025-09-07T16-13-09Z
deploy/docker/README.md the service/image table

Why a pinned tag and not :latest. quay has not moved :latest since 2025-09-07, so both resolve to the same digest today and this changes nothing operationally. It removes the surprise of a silent move later, and keeps the test harness off a floating tag. Whether the kit should track a newer MinIO release, or a different S3-compatible image, is a separate call and not one to fold into an outage fix.

minio/mc (the minio-init one-shot in compose) is a different repository and still resolves on Docker Hub, so it is left alone.

While in the README's image table: the postgres and redis rows had drifted from what compose actually ships (postgres:18-alpine and valkey/valkey:9.1.0-alpine).

Also here: the two advisory fixes, or CI cannot go green

dotnet restore fails for the whole solution under TreatWarningsAsErrors on main right now, so this PR would be red regardless of the MinIO fix. Both are advisory-database drift rather than a code change: a commit green on 2026-08-10 is red today with no edits.

Verification

  • docker pull minio/minio:latest fails with the error quoted above.
  • docker pull quay.io/minio/minio:RELEASE.2025-09-07T16-13-09Z succeeds, digest sha256:14cea493d9a34af32f524e538b8346cf79f3321eff8e708c1e2960462bd8936e, the same digest :latest resolves to.
  • dotnet restore src/FSH.Starter.slnx exits 0 with no NU19xx.
  • dotnet build src/FSH.Starter.slnx -c Release -warnaserror: 0 warnings, 0 errors.
  • dotnet test src/Tests/Integration.Tests -c Release against a real MinIO container on the pinned tag: 0 failed, up from 23 passed / 724 failed before the change.
  • The Aspire manifest (--publisher manifest) renders the container as quay.io/minio/minio:RELEASE.2025-09-07T16-13-09Z, so the registry and tag overrides land where intended. minio/mc stays on Docker Hub, as expected.

Docs

Docs + changelog land in the separate fullstackhero/docs site: fullstackhero/docs#247.

@chatgpt-codex-connector

Copy link
Copy Markdown

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

@marcelo-maciel
marcelo-maciel force-pushed the fix/minio-image-registry branch from 672ce49 to a42d7f5 Compare September 14, 2026 16:29
@marcelo-maciel marcelo-maciel changed the title fix(infra): pull MinIO from quay.io, not Docker Hub fix(infra): pull MinIO from quay.io on a pinned tag, not Docker Hub Sep 14, 2026
…advisories

`dotnet restore` fails for the whole solution under `TreatWarningsAsErrors`, on
`main` and on every open PR alike. Advisory-database drift, not a regression from
any change: a commit green on 2026-08-10 is red today with no edits.

- `Testcontainers.PostgreSql` / `.Redis` / `.Minio` 4.11.0 -> 4.14.0 (NU1903,
  GHSA-q939-rpr3-3284). 4.11.0 depends on `SSH.NET` 2025.1.0; 4.14.0 already
  depends on the patched 2026.0.0, so the advisory clears with no transitive pin
  to remember to remove later. Same fix as fullstackhero#1369, so the two do not conflict.
- `Microsoft.SourceLink.GitHub` 8.0.0 -> 10.0.401 (NU1902,
  GHSA-23fw-v26w-5fgq). 8.0.0 drags in `Microsoft.Build.Tasks.Git` 8.0.0 and the
  8.x line has no patched release, so a transitive pin cannot fix it; the package
  itself has to move. 10.0.401 depends on `Microsoft.Build.Tasks.Git` 10.0.401,
  past the patched 10.0.303. Build-time only (`PrivateAssets="all"`), referenced
  only where `IsPackable == true`, which is the CLI alone - and `src/Tools/**` is
  excluded from the template, so the scaffold never sees it.

Verified: `dotnet restore src/FSH.Starter.slnx` exits 0 with no NU19xx, and
`dotnet build src/FSH.Starter.slnx -c Release -warnaserror` reports 0 warnings
and 0 errors.
MinIO withdrew `minio/minio` from Docker Hub. Docker Hub's API now answers
`object not found` for the repository, and a pull fails with:

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

That takes down every Testcontainers-backed integration test (the harness boots
a MinIO container per fixture, so all 724 tests in `Integration.Tests` fail at
container start), the Aspire AppHost, and the Docker Compose deployment. The
image is still published at `quay.io/minio/minio`:

- `Integration.Tests` and `Integration.Middleware.Tests` harnesses
- `AppHost.cs`, via Aspire's `WithImageRegistry` / `WithImageTag`
- `deploy/docker/docker-compose.yml` and the image table in its README

The tag is pinned to `RELEASE.2025-09-07T16-13-09Z` rather than `:latest`. quay
has not moved `:latest` since 2025-09-07, so the two resolve to the same digest
today; pinning only removes the surprise of a silent move later, and keeps the
test harness off a floating tag. Whether to track a newer release, or a different
S3-compatible image, is a separate call.

While in the README's image table: `postgres` and `redis` rows had drifted from
what compose actually ships (`postgres:18-alpine`, `valkey/valkey:9.1.0-alpine`).

Verified: `docker pull minio/minio:latest` fails with the error above;
`docker pull quay.io/minio/minio:RELEASE.2025-09-07T16-13-09Z` succeeds
(`sha256:14cea493d9a34af32f524e538b8346cf79f3321eff8e708c1e2960462bd8936e`, the
same digest `:latest` resolves to). `dotnet test Integration.Tests -c Release`
passes against the pinned image, and the Aspire manifest renders the container
as `quay.io/minio/minio:RELEASE.2025-09-07T16-13-09Z`.
@marcelo-maciel
marcelo-maciel force-pushed the fix/minio-image-registry branch from a42d7f5 to f1478e6 Compare September 14, 2026 17:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant