bug(infra/minio): create-buckets bootstrap.sh bind-mount fails on DooD runner (Is a directory) #506

New Issue

marcel · 2026-05-11T15:31:42+02:00

marcel commented

2026-05-11 15:31:42 +02:00

Summary

docker-compose.prod.yml's create-buckets service mounts ./infra/minio/bootstrap.sh:/bootstrap.sh:ro. Under Docker-out-of-Docker (the production Gitea Actions runner is DooD), the host Docker daemon resolves the relative path against the host filesystem — not the runner container's /workspace/.... The path doesn't exist on the host, so Docker auto-creates an empty directory at the mount target, and the entrypoint /bin/sh /bootstrap.sh fails with /bootstrap.sh: Is a directory.

Reproduction

$ docker compose -f docker-compose.prod.yml -p test-idem --env-file .env.test run --rm create-buckets
 Container test-idem-minio-1 Running
 Container test-idem-minio-1 Healthy
 Container test-idem-create-buckets-run-... Creating
 Container test-idem-create-buckets-run-... Created
/bootstrap.sh: /bootstrap.sh: Is a directory
exitcode '126': failure

Reproduces on the self-hosted Gitea Actions runner. Works locally on a developer machine because the runner CWD equals the host filesystem path.

Impact

Compose Bucket Idempotency CI job — failing on every PR since #499 landed.
Actual staging + production deploys — nightly.yml and release.yml will hit the same error when the create-buckets service starts. The current production rollout is blocked.

Fix

Bake bootstrap.sh into a tiny derived image. No runtime path resolution required, works in DooD / regular Docker / any environment.

# infra/minio/Dockerfile
FROM minio/mc:RELEASE.2025-08-13T08-35-41Z
COPY bootstrap.sh /bootstrap.sh
RUN chmod +x /bootstrap.sh
ENTRYPOINT ["/bin/sh", "/bootstrap.sh"]

Update docker-compose.prod.yml:

create-buckets:
  build:
    context: ./infra/minio
  # remove: volumes: - ./infra/minio/bootstrap.sh:/bootstrap.sh:ro
  # remove: entrypoint: ["/bin/sh", "/bootstrap.sh"]

The image pin (RELEASE.2025-08-13T08-35-41Z) moves into the Dockerfile FROM line so Renovate-style upgrades still touch one canonical place.

Why the CI test didn't catch this earlier (or rather: caught it but was attributed to a CI bug)

The Compose Bucket Idempotency job IS the regression test — it has been red since merge. The failure was assumed to be a runner-specific quirk; it is actually a real production-deploy blocker.

Discovered

While running nightly.yml to deploy staging for the first time after #499 / #497.

## Summary `docker-compose.prod.yml`'s `create-buckets` service mounts `./infra/minio/bootstrap.sh:/bootstrap.sh:ro`. Under Docker-out-of-Docker (the production Gitea Actions runner is DooD), the host Docker daemon resolves the relative path against the host filesystem — not the runner container's `/workspace/...`. The path doesn't exist on the host, so Docker auto-creates an empty directory at the mount target, and the entrypoint `/bin/sh /bootstrap.sh` fails with `/bootstrap.sh: Is a directory`. ## Reproduction ``` $ docker compose -f docker-compose.prod.yml -p test-idem --env-file .env.test run --rm create-buckets Container test-idem-minio-1 Running Container test-idem-minio-1 Healthy Container test-idem-create-buckets-run-... Creating Container test-idem-create-buckets-run-... Created /bootstrap.sh: /bootstrap.sh: Is a directory exitcode '126': failure ``` Reproduces on the self-hosted Gitea Actions runner. Works locally on a developer machine because the runner CWD equals the host filesystem path. ## Impact - **Compose Bucket Idempotency CI job** — failing on every PR since #499 landed. - **Actual staging + production deploys** — `nightly.yml` and `release.yml` will hit the same error when the create-buckets service starts. The current production rollout is blocked. ## Fix Bake `bootstrap.sh` into a tiny derived image. No runtime path resolution required, works in DooD / regular Docker / any environment. ```dockerfile # infra/minio/Dockerfile FROM minio/mc:RELEASE.2025-08-13T08-35-41Z COPY bootstrap.sh /bootstrap.sh RUN chmod +x /bootstrap.sh ENTRYPOINT ["/bin/sh", "/bootstrap.sh"] ``` Update `docker-compose.prod.yml`: ```yaml create-buckets: build: context: ./infra/minio # remove: volumes: - ./infra/minio/bootstrap.sh:/bootstrap.sh:ro # remove: entrypoint: ["/bin/sh", "/bootstrap.sh"] ``` The image pin (`RELEASE.2025-08-13T08-35-41Z`) moves into the Dockerfile FROM line so Renovate-style upgrades still touch one canonical place. ## Why the CI test didn't catch this earlier (or rather: caught it but was attributed to a CI bug) The Compose Bucket Idempotency job IS the regression test — it has been red since merge. The failure was assumed to be a runner-specific quirk; it is actually a real production-deploy blocker. ## Discovered While running `nightly.yml` to deploy staging for the first time after #499 / #497.

marcel referenced this issue from a commit

2026-05-11 15:33:12 +02:00

fix(minio): bake bootstrap.sh into image instead of bind-mounting

marcel referenced a pull request that will close this issue

2026-05-11 15:33:21 +02:00

fix(minio): bake bootstrap.sh into image instead of bind-mounting (#506) #507

marcel closed this issue

2026-05-11 15:56:06 +02:00

Sign in to join this conversation.