Woodpecker CI

Woodpecker CI

Use this skill as an operating playbook, not as a substitute for checking the documentation for the installed major version. Prefer explicit SemVer image tags, verify the resolved configuration before starting services, and verify runtime health after every change.

Scope boundary: This skill configures and operates Woodpecker CI (the server, agents, workflows, and integrations). It does not install or administer Forgejo/Gitea itself, and it does not configure Forgejo Actions runners. When a task mentions Forgejo, treat it as the forge Woodpecker connects to unless forge administration is explicitly requested.

Operating loop

1. Identify the Woodpecker major version, forge, backend, deployment files, database, public URL, and whether the task is a setup, pipeline, or incident.
2. Read the matching reference below before changing configuration.
3. Render and lint configuration before starting the server or agent.
4. Make the smallest change at the layer that owns the problem: forge/OAuth, server, agent/backend, or repository workflow.
5. Verify the result at the next boundary: server health, agent connected state, repository webhook, pipeline scheduling, step logs, and external deployment endpoint.
6. Record the exact version and relevant environment variables without recording secret values.

Choose the entry point

Then load references/source-index.md when a version-sensitive command or variable needs confirmation.

Quick command card

# Generate a shared server/agent secret
openssl rand -hex 32

# Compose Woodpecker server + agent (not Forgejo itself)
cp templates/docker-compose.yml compose.yaml
cp templates/forgejo.env.example .env
# edit .env, then:
docker compose config --quiet
docker compose up -d
docker compose ps
docker compose logs -f --tail=100 woodpecker-server woodpecker-agent

# Local workflow checks
woodpecker-cli lint .woodpecker.yml
woodpecker-cli exec .woodpecker.yml

# Pipeline and secret administration
woodpecker-cli repo info --repository OWNER/REPO
woodpecker-cli repo secret add --repository OWNER/REPO --name NAME --value @/path/to/value

woodpecker-cli exec is useful for local command and metadata checks, but it is not a complete substitute for a server run: server-managed secrets and forge events may not be available locally.

Core defaults

• Use the Docker backend for isolated container steps. The Docker socket is powerful: treat an agent host as a CI trust boundary.
• Use the Kubernetes backend for pod-per-step isolation and cluster scheduling; review service accounts, namespace boundaries, pull secrets, PVC/storage, and resource requests before allowing repository authors to set backend options.

  Multi-tenant default: For untrusted repositories, prefer Kubernetes with namespace/RBAC/ServiceAccount controls when the cluster is already operated as a security boundary. Docker is a viable simpler default only with dedicated agents and trust-tier separation because the Docker socket controls the host daemon. Never use the Local backend for untrusted repositories.

• The agent needs WOODPECKER_SERVER and the same WOODPECKER_AGENT_SECRET as the server. The server registers an agent on first contact; persist the agent config file so its generated identity survives restarts.
• Keep WOODPECKER_OPEN=false unless open registration is intentional. Grant admin access explicitly and protect the OAuth client secret and agent secret.
• Do not expose secrets to untrusted pull requests by default. If a secret must be available there, restrict its events and plugin images and document the threat model.
• depends_on is for workflow ordering and parallelism; it is not a readiness check for service containers. Add a real wait/backoff or health probe for databases and caches.
• A step's when list is OR across entries and AND within one entry. Branch filters also affect pull-request target branches; combine event and branch when you mean pushes to a branch only.
• A passing docker compose config or CLI lint proves syntax/model validity, not that the agent can reach the forge, the image can pull, or the pipeline is safe.

Reference routing

Included artifacts

• templates/docker-compose.yml — minimal server plus Docker agent deployment.
• templates/woodpecker.yml — conservative build/test/deploy workflow skeleton.
• templates/forgejo.env.example — placeholder environment contract for Forgejo.
• assets/troubleshooting-checklist.md — incident handoff checklist.
• scripts/woodpecker-doctor.py — dependency-free connectivity/configuration probe with text or JSON output.

Available Scripts

Prerequisites

• Network reachability from where you run the probe to the Woodpecker server URL and, when checking agents, the agent's gRPC host:port.
• Python 3 only — the probe uses the standard library and no third-party packages; it never mutates the Woodpecker instance.
• For actual administration beyond probing (per compatibility): access to the Woodpecker instance, and Docker Compose, Kubernetes, or woodpecker-cli depending on the backend in use — see references/setup.md and references/cli.md.

Limitations

• The doctor probe reports connectivity and configuration signals only; a green probe does not prove forge OAuth works, pipelines schedule, or steps can pull images — verify at those boundaries separately (see Common failure boundaries).
• It reads nothing about repository-level state (webhooks, secrets, queue depth); use the server API/UI and references/troubleshooting.md for that.
• The skill documents operating patterns, not a pinned version: always confirm version-sensitive commands and variables against the installed major version via references/source-index.md.

Common failure boundaries

• Server starts but repositories do not appear: inspect forge OAuth URL, callback URL, scopes, and server logs before changing pipeline YAML. For a push with no pipeline, inspect the Forgejo repository's Settings → Webhooks → Recent Deliveries first and record the delivery status.
• Agent is connected but never picks up work: compare labels/backend, maximum workflows, repository visibility/trust, and agent logs.
• A clone fails: first test network/DNS and credentials from an intentionally paused step; do not debug application commands until checkout works.
• A service is running but tests fail to connect: use the service hostname and container port, then add readiness handling.
• A secret is empty: check secret scope, event filters, plugin-image filters, and expression escaping ($${NAME} when Woodpecker must pass the variable to the shell).

When not to use

Use a forge-specific skill for installing or administering Forgejo/Gitea itself, a Kubernetes operations skill for cluster lifecycle, and a Docker security skill for host hardening. This skill covers Woodpecker's integration points and CI behavior.