d832a33039
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.
79 lines
3 KiB
YAML
79 lines
3 KiB
YAML
server:
|
|
enabled: true
|
|
podAnnotations:
|
|
reloader.stakater.com/search: "true"
|
|
statefulSet:
|
|
replicaCount: 1
|
|
# NOTE: hostAliases is NOT exposed by the woodpecker Helm chart (3.5.1 verified) —
|
|
# see main.tf null_resource.woodpecker_server_host_alias which applies the same
|
|
# via `kubectl patch` post-helm. Pinned to the in-cluster Traefik LB
|
|
# (10.0.20.200) so the forge-API fetch path never round-trips through
|
|
# Cloudflare ("context deadline exceeded" was failing every Forgejo
|
|
# pipeline trigger).
|
|
image:
|
|
registry: docker.io
|
|
repository: woodpeckerci/woodpecker-server
|
|
# Bumped 2026-05-07 from v3.13.0 → v3.14.0 to fix the
|
|
# "could not load config from forge: context deadline exceeded"
|
|
# issue when fetching .woodpecker.yml from Forgejo.
|
|
tag: "v3.14.0"
|
|
extraSecretNamesForEnvFrom:
|
|
- woodpecker-db-creds
|
|
env:
|
|
WOODPECKER_HOST: "https://ci.viktorbarzin.me"
|
|
WOODPECKER_ADMIN: "${woodpecker_admins}"
|
|
WOODPECKER_OPEN: "true"
|
|
WOODPECKER_GITHUB: "true"
|
|
WOODPECKER_GITHUB_URL: "https://github.com"
|
|
WOODPECKER_GITHUB_CLIENT: "${github_client_id}"
|
|
WOODPECKER_GITHUB_SECRET: "${github_client_secret}"
|
|
WOODPECKER_AGENT_SECRET: "${agent_secret}"
|
|
WOODPECKER_DATABASE_DRIVER: "postgres"
|
|
WOODPECKER_PLUGINS_PRIVILEGED: "woodpeckerci/plugin-docker-buildx,plugins/docker"
|
|
WOODPECKER_PLUGINS_TRUSTED_CLONE: "woodpeckerci/plugin-git,alpine"
|
|
WOODPECKER_LOG_LEVEL: "info"
|
|
WOODPECKER_FORGEJO: "true"
|
|
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
|
|
# Disable built-in ingress (using ingress_factory)
|
|
ingress:
|
|
enabled: false
|
|
# Disable PVC (using PostgreSQL instead of SQLite)
|
|
# Note: the correct key is persistentVolume, not persistence
|
|
persistentVolume:
|
|
enabled: false
|
|
|
|
agent:
|
|
enabled: true
|
|
podAnnotations:
|
|
reloader.stakater.com/search: "true"
|
|
replicaCount: 2
|
|
image:
|
|
registry: docker.io
|
|
repository: woodpeckerci/woodpecker-agent
|
|
tag: "v3.14.0"
|
|
env:
|
|
WOODPECKER_BACKEND: "kubernetes"
|
|
WOODPECKER_BACKEND_K8S_NAMESPACE: "woodpecker"
|
|
WOODPECKER_BACKEND_K8S_PULL_SECRET_NAMES: "registry-credentials"
|
|
WOODPECKER_MAX_WORKFLOWS: "2"
|
|
WOODPECKER_AGENT_SECRET: "${agent_secret}"
|
|
persistence:
|
|
enabled: false
|
|
rbac:
|
|
create: true
|
|
serviceAccount:
|
|
create: true
|
|
name: "woodpecker-agent"
|