docker-compose.prod.yml

@@ -80,7 +80,12 @@ services:
   # logic is readable, reviewable, and unit-testable as a script rather
   # than YAML-escaped shell.
   create-buckets:
-    image: minio/mc:RELEASE.2025-08-13T08-35-41Z
+    # Custom image bakes bootstrap.sh in at build time. A bind-mount fails on
+    # the Docker-out-of-Docker production runner because the host daemon
+    # resolves the relative path against the host filesystem, not the
+    # runner container's CWD. See #506 + infra/minio/Dockerfile.
+    build:
+      context: ./infra/minio
     depends_on:
       minio:
         condition: service_healthy
@@ -89,9 +94,6 @@ services:
     environment:
       MINIO_PASSWORD: ${MINIO_PASSWORD}
       MINIO_APP_PASSWORD: ${MINIO_APP_PASSWORD}
-    volumes:
-      - ./infra/minio/bootstrap.sh:/bootstrap.sh:ro
-    entrypoint: ["/bin/sh", "/bootstrap.sh"]
 
   # Dev-only mail catcher; gated behind the staging profile so production
   # never starts it. Staging workflow runs with `--profile staging`.

infra/minio/Dockerfile

@@ -0,0 +1,16 @@
+# Derived MinIO Client image with the idempotent bootstrap script baked in.
+#
+# Why a custom image instead of a bind-mount?
+# The production Gitea Actions runner is Docker-out-of-Docker. A
+# `./infra/minio/bootstrap.sh:/bootstrap.sh:ro` mount resolves the path
+# against the HOST filesystem (the host daemon owns the bind), not the
+# runner container's `/workspace/...`. The path doesn't exist on the host
+# and Docker auto-creates an empty directory at the mount target — the
+# entrypoint then fails with `/bootstrap.sh: Is a directory`. Baking the
+# script in removes runtime path resolution entirely. See #506.
+FROM minio/mc:RELEASE.2025-08-13T08-35-41Z
+
+COPY bootstrap.sh /bootstrap.sh
+RUN chmod +x /bootstrap.sh
+
+ENTRYPOINT ["/bin/sh", "/bootstrap.sh"]