Pins all FROM image tags to exact SHA256 digests for reproducible builds. Without digest pinning, a registry push of a new image to the same tag can silently change the layer content between builds — a supply-chain risk especially for prod-deployed images. Pinned images (7 Dockerfiles): - golang:1.25-alpine → sha256:c4ea15b... (workspace-server/Dockerfile, Dockerfile.dev, Dockerfile.tenant, tests/harness/cp-stub/Dockerfile) - alpine:3.20 → sha256:c64c687c... (workspace-server/Dockerfile, tests/harness/cp-stub/Dockerfile) - node:20-alpine → sha256:afdf982... (workspace-server/Dockerfile.tenant) - node:22-alpine → sha256:cb15fca... (canvas/Dockerfile) - python:3.11-slim → sha256:e78299e... (workspace/Dockerfile) - nginx:1.27-alpine → sha256:62223d6... (tests/harness/cf-proxy/Dockerfile) Note: docker-compose.yml service images (postgres, redis, clickhouse, litellm, ollama) are intentionally left on major-version tags — those are runtime-pulled and updated regularly for local-dev ergonomics. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
15 lines
815 B
Docker
15 lines
815 B
Docker
# cf-proxy harness image — nginx + the harness's tenant-routing config baked
|
|
# in at build time.
|
|
#
|
|
# Why bake (not bind-mount): on Gitea Actions / act_runner, the runner is a
|
|
# container talking to the OUTER docker daemon over the host socket; runc
|
|
# resolves bind-mount source paths on the outer host filesystem, where the
|
|
# repo at `/workspace/.../tests/harness/cf-proxy/nginx.conf` is invisible.
|
|
# Compose `configs:` (with `file:`) falls back to bind mounts when swarm is
|
|
# not active, so it hits the same gap. A build-time COPY uploads the file
|
|
# as part of the docker build context — the daemon receives the tarball
|
|
# directly and never bind-mounts. See issue #88 item 2.
|
|
FROM nginx:1.27-alpine@sha256:62223d644fa234c3a1cc785ee14242ec47a77364226f1c811d2f669f96dc2ac8
|
|
|
|
COPY nginx.conf /etc/nginx/nginx.conf
|