Description
actions/setup-sigstore-env's run-containers.sh clones fulcio, rekor, timestamp-authority, and rekor-tiles fresh on every run and brings each up with docker compose up --wait (which implicitly builds, since no image exists yet for a freshly cloned repo). Those builds run go mod download inside the Dockerfile, and that step has no retry logic anywhere in the script. When proxy.golang.org has a transient hiccup mid-fetch, the whole job fails outright:
go: github.com/google/certificate-transparency-go@v1.3.3: read "https://proxy.golang.org/.../v1.3.3.zip": unexpected EOF
target fulcio-server: failed to solve: process "/bin/sh -c go mod download" did not complete successfully: exit code: 1
This is currently a live, ongoing flake, not a one-off — it's still failing consumers of this action today, and it isn't new:
- Two failures today (2026-08-18), 20 minutes apart, on unrelated commits of a downstream PR using this action: https://github.com/sigstore/sigstore-go/actions/runs/32170769773
- The identical signature (
unexpected EOF from proxy.golang.org on a go mod download inside the fulcio-server/rekor build stage) on 2026-07-30, three weeks earlier, on a completely unrelated commit: https://github.com/sigstore/sigstore-go/actions/runs/30547643994
- Across the last 20
e2e runs on sigstore-go's main branch, 11/20 (55%) failed with this same signature, spanning commits with no relation to each other — this is a shared-infra flake in setup-sigstore-env, not anything specific to any one PR or consumer repo.
Each failure re-clones the dependent repos and rebuilds from scratch with no retry, so a single transient proxy.golang.org blip on any one of ~15+ Go module fetches (across 4 separately-built services) fails the whole job. Given the failure is a different specific module each time, this looks like ordinary transient proxy flakiness rather than anything actually broken in the fetched modules or the Dockerfiles themselves.
Proposed fix
Wrap the docker compose up --wait [--build] calls in run-containers.sh with a small retry-with-backoff. Docker's build layer cache means a retry mostly just re-runs the one layer that failed (go mod download), not the whole multi-minute build, so this should be cheap and should resolve the large majority of these failures without touching the downstream repos' own Dockerfiles individually.
I'd like to pick this up — will follow up with a PR.
Description
actions/setup-sigstore-env'srun-containers.shclonesfulcio,rekor,timestamp-authority, andrekor-tilesfresh on every run and brings each up withdocker compose up --wait(which implicitly builds, since no image exists yet for a freshly cloned repo). Those builds rungo mod downloadinside the Dockerfile, and that step has no retry logic anywhere in the script. Whenproxy.golang.orghas a transient hiccup mid-fetch, the whole job fails outright:This is currently a live, ongoing flake, not a one-off — it's still failing consumers of this action today, and it isn't new:
unexpected EOFfromproxy.golang.orgon ago mod downloadinside thefulcio-server/rekorbuild stage) on 2026-07-30, three weeks earlier, on a completely unrelated commit: https://github.com/sigstore/sigstore-go/actions/runs/30547643994e2eruns onsigstore-go'smainbranch, 11/20 (55%) failed with this same signature, spanning commits with no relation to each other — this is a shared-infra flake insetup-sigstore-env, not anything specific to any one PR or consumer repo.Each failure re-clones the dependent repos and rebuilds from scratch with no retry, so a single transient
proxy.golang.orgblip on any one of ~15+ Go module fetches (across 4 separately-built services) fails the whole job. Given the failure is a different specific module each time, this looks like ordinary transient proxy flakiness rather than anything actually broken in the fetched modules or the Dockerfiles themselves.Proposed fix
Wrap the
docker compose up --wait [--build]calls inrun-containers.shwith a small retry-with-backoff. Docker's build layer cache means a retry mostly just re-runs the one layer that failed (go mod download), not the whole multi-minute build, so this should be cheap and should resolve the large majority of these failures without touching the downstream repos' own Dockerfiles individually.I'd like to pick this up — will follow up with a PR.