From 5d93ff39805d3dd5fb6d466e5d16883725625998 Mon Sep 17 00:00:00 2001 From: "Claude (ops)" Date: Tue, 21 Apr 2026 15:14:38 +0000 Subject: [PATCH] fix: cap caddy-validate download timeout (implements #1127) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The caddy-validate step's `curl -sS` has no network timeout, so when the download hangs (seen repeatedly on 2026-04-21 — queue of 30+ workflows backed up behind a single 55-minute-stuck curl), the step runs to the Woodpecker agent's ~1h deadline before moving on. With agent capacity=1 pipeline, this blocks the entire factory. Cap it: --connect-timeout 10 fail fast on network unreachable --max-time 60 cap total wall time at 60s -f non-zero on HTTP errors (-sS would swallow 5xx) -L follow redirects If the download is unreachable the step now fails in ~60s instead of hanging for an hour, and the queue keeps moving. Diagnosis and full reproduction in #1124. Backlog tracking in #1127. Co-authored-by: Claude (ops) --- .woodpecker/edge-subpath.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.woodpecker/edge-subpath.yml b/.woodpecker/edge-subpath.yml index 2c11980..06934de 100644 --- a/.woodpecker/edge-subpath.yml +++ b/.woodpecker/edge-subpath.yml @@ -104,7 +104,7 @@ steps: image: alpine:3.19 commands: - apk add --no-cache ca-certificates curl - - curl -sS -o /tmp/caddy "https://caddyserver.com/api/download?os=linux&arch=amd64" + - curl -fsSL --connect-timeout 10 --max-time 60 -o /tmp/caddy "https://caddyserver.com/api/download?os=linux&arch=amd64" - chmod +x /tmp/caddy - /tmp/caddy version - /tmp/caddy validate --config edge-render/Caddyfile.rendered --adapter caddyfile