Declare the secret's pull event the way Woodpecker spells it #68

Merged

tepichord merged 1 commit from fix/woodpecker-secret-events into main

2026-09-17 11:42:55 -07:00

tepichord commented

2026-09-17 11:37:19 -07:00

Owner

Description

Merging the secret extension (#67) wired the path up, and the first pipeline to
use it proved the path works end to end — the signed request arrived, Vault
answered, the value came back — and then Woodpecker refused it at pipeline
creation:

secret "FORGEJO_TOKEN" is not allowed to be used with pipeline event "pull_request_closed"

Pipeline #6 in tepichord/annia-infra is stored as error with zero steps,
so nothing in a step log explained it. The cause is two programs reading an
event list in two vocabularies:

the extension matches a rule's events against the raw pipeline event
(internal/rules/rules.go), so pull_request_closed is correct there and is
the closed-only gate;
Woodpecker checks the secret-level list with compiler.Secret.Match,
which rewrites every pull event to pull_request before comparing — so
pull_request_closed there is refused on the one event it was written for.

The secret entry now says pull_request. The rule is unchanged, so the token is
still only served to pull_request_closed pipelines, and any other pull event
fails as an unresolvable secret reference (secret "FORGEJO_TOKEN" not found)
rather than as a leak.

Changes

apps/woodpecker/secret-extension.yaml: secret-level events: ["pull_request"]
with a comment recording why the two lists cannot hold the same string.
tests/test_gitops.py: tripwire that mirrors Woodpecker's Event.IsPull and
fails if a pull-event rule's secret omits pull_request. Verified to fail with
the bug reintroduced.
OPERATIONS.md §9k: the failure shape (a pipeline error with no steps), the
fact that the config file is read only at start-up (so a rule change needs
rollout restart), and the POST /repos/1/pipelines/<n> call that re-runs a
pipeline so a rule change can be tested without another merge.

Testing

kustomize build of both layers (12 / 8 objects), conftest 48 + 32 tests,
kubeconform -strict 12 valid, python3 -m pytest tests/ 173 passed / 31
skipped.
Tripwire fails when pull_request_closed is put back.

Follow-up (not in this PR)

After this merges, the extension needs a restart to pick the rule up, then
pipeline #6 can be re-run to confirm a green pull_request_closed run:
kubectl -n woodpecker rollout restart deploy/woodpecker-secret-extension,
then POST /api/repos/1/pipelines/6.

## Description Merging the secret extension (#67) wired the path up, and the first pipeline to use it proved the path works end to end — the signed request arrived, Vault answered, the value came back — and then Woodpecker refused it at pipeline creation: ``` secret "FORGEJO_TOKEN" is not allowed to be used with pipeline event "pull_request_closed" ``` Pipeline #6 in `tepichord/annia-infra` is stored as `error` with **zero steps**, so nothing in a step log explained it. The cause is two programs reading an event list in two vocabularies: - the **extension** matches a rule's `events` against the raw pipeline event (`internal/rules/rules.go`), so `pull_request_closed` is correct there and is the closed-only gate; - **Woodpecker** checks the *secret-level* list with `compiler.Secret.Match`, which rewrites every pull event to `pull_request` before comparing — so `pull_request_closed` there is refused on the one event it was written for. The secret entry now says `pull_request`. The rule is unchanged, so the token is still only served to `pull_request_closed` pipelines, and any other pull event fails as an unresolvable secret reference (`secret "FORGEJO_TOKEN" not found`) rather than as a leak. ## Changes - `apps/woodpecker/secret-extension.yaml`: secret-level `events: ["pull_request"]` with a comment recording why the two lists cannot hold the same string. - `tests/test_gitops.py`: tripwire that mirrors Woodpecker's `Event.IsPull` and fails if a pull-event rule's secret omits `pull_request`. Verified to fail with the bug reintroduced. - `OPERATIONS.md` §9k: the failure shape (a pipeline `error` with no steps), the fact that the config file is read only at start-up (so a rule change needs `rollout restart`), and the `POST /repos/1/pipelines/<n>` call that re-runs a pipeline so a rule change can be tested without another merge. ## Testing - `kustomize build` of both layers (12 / 8 objects), `conftest` 48 + 32 tests, `kubeconform -strict` 12 valid, `python3 -m pytest tests/` 173 passed / 31 skipped. - Tripwire fails when `pull_request_closed` is put back. ## Follow-up (not in this PR) After this merges, the extension needs a restart to pick the rule up, then pipeline #6 can be re-run to confirm a green `pull_request_closed` run: `kubectl -n woodpecker rollout restart deploy/woodpecker-secret-extension`, then `POST /api/repos/1/pipelines/6`.

tepichord added 1 commit

2026-09-17 11:37:19 -07:00

Declare the secret's pull event the way Woodpecker spells it

ci/woodpecker/pr/gates Pipeline was successful

Details

ci/woodpecker/pull_request_closed/cleanup Pipeline was successful

Details

b425092611

`pull_request_closed` is the right value for the rule's `events` — the
extension matches that list against the raw pipeline event — but it cannot be
the secret-level one: `compiler.Secret.Match` rewrites every pull event to
`pull_request` before it compares, so the secret was refused on the one event
it exists for. Merging the extension proved it: pipeline #6 in
tepichord/annia-infra was stored as `error` with no steps and the message
`secret "FORGEJO_TOKEN" is not allowed to be used with pipeline event
"pull_request_closed"` — which is also why no step log explained it.

The rule's list stays closed-only and the extension stays the gate: any other
pull event now fails as an unresolvable secret reference instead of as a leak.

The test holds the two lists to the vocabularies they are read in, and
OPERATIONS §9k records the failure shape, the "config is read once, at
start-up" restart, and the POST that re-runs a pipeline so a rule change can
be tested without a second merge.