From d832a330392618c9900cc6be16ec27bf995f02f7 Mon Sep 17 00:00:00 2001 From: Viktor Barzin Date: Thu, 7 May 2026 23:10:48 +0000 Subject: [PATCH] =?UTF-8?q?[woodpecker]=20Bump=20WOODPECKER=5FFORGE=5FTIME?= =?UTF-8?q?OUT=203s=20=E2=86=92=2030s?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The default forge-API timeout is 3 seconds. The config-loader makes 4-6 sequential calls per pipeline trigger (probing for .woodpecker dir then each .woodpecker.{yaml,yml} variant), and Forgejo responses on this cluster spike to 1-2s under load — easy to trip the cumulative 3s deadline. Result: 'could not load config from forge: context deadline exceeded' on virtually every pipeline trigger. This was the actual root cause of the 'Woodpecker forge-API bug' that v3.13 → v3.14 was supposed to fix — turns out v3.14 didn't change the timeout default, and the v3.13 successes I saw earlier were warm-cache flukes. --- stacks/woodpecker/values.yaml | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/stacks/woodpecker/values.yaml b/stacks/woodpecker/values.yaml index d34fc633..efb7ca52 100644 --- a/stacks/woodpecker/values.yaml +++ b/stacks/woodpecker/values.yaml @@ -36,6 +36,14 @@ server: WOODPECKER_FORGEJO_CLIENT: "${forgejo_client_id}" WOODPECKER_FORGEJO_SECRET: "${forgejo_client_secret}" WOODPECKER_FORGEJO_URL: "${forgejo_url}" + # Default is 3s (cmd/server/flags.go @ default `--forge-timeout`). + # Forgejo responses on this cluster spike to 1-2s under load and the + # config-loader makes 4-6 sequential calls (.woodpecker dir, .woodpecker.yaml, + # .woodpecker.yml, raw .woodpecker/build.yml, etc.); occasionally the cumulative + # overhead trips the 3s deadline → "could not load config from forge: context + # deadline exceeded" on every pipeline. 30s removes the false-positive timeouts + # without regressing the legitimate-failure detection window meaningfully. + WOODPECKER_FORGE_TIMEOUT: "30s" service: type: ClusterIP port: 80