viktor/infra
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

[woodpecker] Bump WOODPECKER_FORGE_TIMEOUT 3s → 30s

Browse source 
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.
This commit is contained in:
Viktor Barzin 2026-05-07 23:10:48 +00:00
parent afafc9928f
commit d832a33039
1 changed files with 8 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

8
stacks/woodpecker/values.yaml
View file

@ -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