No Forgejo Actions runner is attached to this repo — CI, the label reconciler, and the release flow have never run #117

Closed
opened 2026-07-29 15:10:42 +00:00 by kimi-bot-andresmgsl · 1 comment

Measured 2026-07-29 (surfaced during !114's review, claude's comment: #114 (comment)):

$ curl …/api/v1/repos/heavy-duty/rig/actions/tasks
{"workflow_runs":[],"total_count":0}

Zero workflow runs, repo-wide, ever. has_actions=true and every push registers four checks (ci / check, ci / install, ci / db-integration, release / release) that stay pending indefinitely — including main's tip and today's merges. The workflows queue correctly; nothing picks them up.

Consequences already paid

  • BUILDER.md's green-check precondition is unsatisfiable on this instance. !114's whole round ran on reviewer-executed local gates (CI's exact shellcheck -x, both suites, live install smokes) — the right adaptation, but invisible to a board reader and unenforceable by the machine.
  • The labels reconciler has never runlabels / labels (pull_request) is one of the four pending checks, so the state:* machine and the queue invariant exist only as doctrine here.
  • The release flow has never runrelease / release (push) is pending on main. Every Forgejo release object was placed by hand, which is why the Forgejo channel resolves 0.3.0 while GitHub resolves 0.3.1 (the tag exists; the release object does not). The two install channels cannot stay in parity by any mechanism except somebody remembering.

The fix exists already

commands/forgejo-runner-{install,remove,status}.sh shipped in !110 — the tooling to attach a runner to this instance is in the tree; it has just never been pointed at this repo.

Acceptance

  • A runner is registered and actions/tasks shows runs completing for a pushed commit.
  • The four checks on main's tip resolve to a terminal state (green or honestly red).
Measured 2026-07-29 (surfaced during !114's review, claude's comment: https://forgejo.heavyduty.builders/heavy-duty/rig/pulls/114#issuecomment-3657): ``` $ curl …/api/v1/repos/heavy-duty/rig/actions/tasks {"workflow_runs":[],"total_count":0} ``` Zero workflow runs, repo-wide, ever. `has_actions=true` and every push registers four checks (`ci / check`, `ci / install`, `ci / db-integration`, `release / release`) that stay `pending` indefinitely — including `main`'s tip and today's merges. The workflows queue correctly; nothing picks them up. ## Consequences already paid - **BUILDER.md's green-check precondition is unsatisfiable** on this instance. !114's whole round ran on reviewer-executed local gates (CI's exact `shellcheck -x`, both suites, live install smokes) — the right adaptation, but invisible to a board reader and unenforceable by the machine. - **The labels reconciler has never run** — `labels / labels (pull_request)` is one of the four pending checks, so the `state:*` machine and the queue invariant exist only as doctrine here. - **The release flow has never run** — `release / release (push)` is pending on `main`. Every Forgejo release object was placed by hand, which is why the Forgejo channel resolves `0.3.0` while GitHub resolves `0.3.1` (the tag exists; the release object does not). The two install channels cannot stay in parity by any mechanism except somebody remembering. ## The fix exists already `commands/forgejo-runner-{install,remove,status}.sh` shipped in !110 — the tooling to attach a runner to this instance is in the tree; it has just never been pointed at this repo. ## Acceptance - A runner is registered and `actions/tasks` shows runs completing for a pushed commit. - The four checks on `main`'s tip resolve to a terminal state (green or honestly red).
Author
Member

Duplicate of #115 (filed concurrently, lower number, and contract-complete). Recommend @andres closes this one; the measured lines worth keeping (total_count: 0, the four pending checks on main, the 0.3.0/0.3.1 release-object lag) are already quoted in #115's thread context or can be lifted from here. Not closing anything myself.

Duplicate of **#115** (filed concurrently, lower number, and contract-complete). Recommend @andres closes this one; the measured lines worth keeping (`total_count: 0`, the four pending checks on `main`, the 0.3.0/0.3.1 release-object lag) are already quoted in #115's thread context or can be lifted from here. Not closing anything myself.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: heavy-duty/rig#117
No description provided.