Forgejo Actions runner not picking up recent main pushes (no CI runs for 2 commits) #214

New issue

Open

opened 2026-06-04 08:50:26 +00:00 by coilysiren · 0 comments

coilysiren commented

2026-06-04 08:50:26 +00:00

Owner

Symptom

Two consecutive pushes to main produced no Forgejo Actions runs:

fc50503 - git role (ansible)
c986b01 - feat(ansible): add keepawake role ... (closes #213)

coily ops forgejo actions task list --repo coilyco-flight-deck/infrastructure still shows the newest task as run#137 for 8eb40580 (fix(coily-update): cap memory ...), which predates both pushes.

Why this is unexpected

Both .forgejo/workflows/lint.yml and .forgejo/workflows/trufflehog.yml trigger on push: branches: [main] with no path filter, so every main push should enqueue lint + Scan for secrets. Zero runs for two separate pushes points at the in-cluster runner (deploy/forgejo-runner.yml) being offline, deregistered, or its queue stalled - rather than a per-commit skip.

Impact

Low for the two commits in question: their equivalent checks passed locally via pre-commit (pylint "matches the CI lint job", offline trufflehog). But while the runner is down, no main push is actually CI-verified, so the release-rule CI gate is silently a no-op.

Next step

Check runner registration / pod health on kai-server (k3s kubectl -n forgejo ...), confirm it reconnects, and re-trigger or confirm runs land for the two commits above.

## Symptom Two consecutive pushes to `main` produced **no Forgejo Actions runs**: - `fc50503` - `git` role (ansible) - `c986b01` - `feat(ansible): add keepawake role ...` (closes #213) `coily ops forgejo actions task list --repo coilyco-flight-deck/infrastructure` still shows the newest task as `run#137` for `8eb40580` (`fix(coily-update): cap memory ...`), which predates both pushes. ## Why this is unexpected Both `.forgejo/workflows/lint.yml` and `.forgejo/workflows/trufflehog.yml` trigger on `push: branches: [main]` with **no path filter**, so every main push should enqueue `lint` + `Scan for secrets`. Zero runs for two separate pushes points at the in-cluster runner (`deploy/forgejo-runner.yml`) being offline, deregistered, or its queue stalled - rather than a per-commit skip. ## Impact Low for the two commits in question: their equivalent checks passed locally via pre-commit (`pylint` "matches the CI lint job", offline trufflehog). But while the runner is down, no main push is actually CI-verified, so the release-rule CI gate is silently a no-op. ## Next step Check runner registration / pod health on kai-server (`k3s kubectl -n forgejo ...`), confirm it reconnects, and re-trigger or confirm runs land for the two commits above.

coilysiren added the

label

2026-06-17 07:05:00 +00:00

coilysiren added

and removed

labels

2026-06-17 08:39:59 +00:00