release pipeline never fires: Actions runner has serviced zero tasks, releases cut by hand #107

New issue

Closed

opened 2026-06-07 17:30:44 +00:00 by coilysiren · 1 comment

coilysiren commented

2026-06-07 17:30:44 +00:00

Owner

Symptom

The Forgejo-canonical release pipeline (.forgejo/workflows/release.yml, on: push -> main) has never executed. Evidence at v0.4.0 release time:

coily ops forgejo actions task list --repo coilyco-flight-deck/cli-guard -> (no tasks) (runner has never picked up a single run for this repo)
coily ops forgejo release list was empty before today (tags v0.1.0-v0.3.0 exist on the remote but have no release objects -> all cut by hand)
has_actions: true on the repo, default branch main, yet 14 feat commits accumulated since v0.3.0 with no v0.4.0 tag auto-cut

So v0.4.0 had to be released manually: annotated tag at main HEAD pushed to Forgejo, then coily ops forgejo release create. The semver bump (v0.3.0 -> v0.4.0, minor) was computed by hand from conventional commits, exactly what tag-bump should have done.

Likely cause

Actions is enabled on the repo but no runner ever serviced it. Candidates: no runner registered for the runs-on: docker label reachable from this repo, or the workflow was added (commit 580b035) after the relevant pushes and nothing has pushed to main since to trigger it. Since on: is push -> branches:[main] (not tag push), a tag push does not re-trigger it, and main is already at the tip.

Fix

Confirm a Forgejo Actions runner with the docker label is registered and visible to coilyco-flight-deck/cli-guard.
Trigger one real run (a no-op push to main, or a workflow_dispatch trigger added to the workflow) and confirm tag-bump + create-release succeed end to end, so the next feat/fix releases without manual intervention.
Consider adding workflow_dispatch to release.yml so a release can be kicked manually without a dummy commit when main is already at the tip.

Until this is fixed, every cli-guard release is a manual tag + coily ops forgejo release create.

## Symptom The Forgejo-canonical release pipeline (`.forgejo/workflows/release.yml`, `on: push -> main`) has **never executed**. Evidence at v0.4.0 release time: - `coily ops forgejo actions task list --repo coilyco-flight-deck/cli-guard` -> `(no tasks)` (runner has never picked up a single run for this repo) - `coily ops forgejo release list` was **empty** before today (tags v0.1.0-v0.3.0 exist on the remote but have no release objects -> all cut by hand) - `has_actions: true` on the repo, default branch `main`, yet 14 `feat` commits accumulated since v0.3.0 with no `v0.4.0` tag auto-cut So v0.4.0 had to be released manually: annotated tag at main HEAD pushed to Forgejo, then `coily ops forgejo release create`. The semver bump (v0.3.0 -> v0.4.0, minor) was computed by hand from conventional commits, exactly what `tag-bump` should have done. ## Likely cause Actions is enabled on the repo but no runner ever serviced it. Candidates: no runner registered for the `runs-on: docker` label reachable from this repo, or the workflow was added (commit 580b035) after the relevant pushes and nothing has pushed to `main` since to trigger it. Since `on:` is `push -> branches:[main]` (not tag push), a tag push does not re-trigger it, and main is already at the tip. ## Fix - Confirm a Forgejo Actions runner with the `docker` label is registered and visible to coilyco-flight-deck/cli-guard. - Trigger one real run (a no-op push to main, or a `workflow_dispatch` trigger added to the workflow) and confirm `tag-bump` + `create-release` succeed end to end, so the next `feat`/`fix` releases without manual intervention. - Consider adding `workflow_dispatch` to `release.yml` so a release can be kicked manually without a dummy commit when main is already at the tip. Until this is fixed, every cli-guard release is a manual tag + `coily ops forgejo release create`.

coilysiren referenced this issue

2026-06-10 17:34:57 +00:00

godoc-current.txt is GOOS-dependent (sandbox per-OS docs); cross-platform commits trip the hook #126

coilysiren added the

label

2026-06-17 07:04:48 +00:00

coilysiren commented

2026-06-17 08:23:19 +00:00

Author

Owner

Backlog burndown 2026-06-17: closing low-priority (P3/P4) to bring the open count to a manageable level. Nothing lost — reopen if this resurfaces. Batch tag: burndown-2026-06.

Backlog burndown 2026-06-17: closing low-priority (P3/P4) to bring the open count to a manageable level. Nothing lost — reopen if this resurfaces. Batch tag: `burndown-2026-06`.

coilysiren

2026-06-17 08:23:19 +00:00