No Actions runner has ever served this repo — every check on every commit is permanently pending #121

New issue

Closed

opened 2026-07-29 15:13:37 +00:00 by claude-bot-andresmgsl · 1 comment

claude-bot-andresmgsl commented

2026-07-29 15:13:37 +00:00

Member

Forgejo Actions is enabled on this repository and has never executed a single
job. Measured 2026-07-29:

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

Every push registers its checks and they stay pending forever — not just on
open PRs, but on main and on commits merged days ago:

commit	checks
`ec73c86` (!114 head)	`pending` × 4
`90cbfe0` (`main` tip)	`pending` × 4 — `ci / check`, `ci / install`, `ci / db-integration`, `release / release`
the four commits before it on `main`	`pending` × 4 each

has_actions=true, the workflows parse, the jobs queue. Nothing has ever picked
one up.

Consequences, all of them currently load-bearing

BUILDER.md's review-round precondition is unsatisfiable. "A review
request requires a green check at the head", and its ruled terms make anything
not affirmatively concluded not-green. No PR on this instance can ever show
one. !114 ran its whole four-round review on reviewer-executed local gates
instead — correct under the circumstances, and invisible to anyone reading the
board.
The labels reconciler has never run. labels / labels (pull_request) is
one of the four pending checks, so state:*, blocker:*, stale and the
work-queue sweep have never been computed here. Combined with the missing
taxonomy labels, the entire label state machine is inert.
The release workflow has never run. release / release (push) is pending
on main. This is why the mirror lags: /releases/latest resolves 0.3.0
here and 0.3.1 on GitHub, and the 0.3.1 tag exists locally with no release
object behind it. Releases are cut by CI and this instance has no CI to cut
them — every release object here was placed by hand.
The --host yes drill gate cannot run, so a release PR's
drill-recorded guard has no evidence path.

Consequence 3 is the mechanical answer to @andres's open question on !114 about
release-channel parity: without a runner the Forgejo channel cannot stay current
by any mechanism except somebody remembering.

Spec

Attach a Forgejo Actions runner able to serve this repository. rig already ships
the tooling from #109 / !110 — commands/forgejo-runner-install.sh,
forgejo-runner-status.sh, forgejo-runner-remove.sh — so this is a
registration and hosting decision, not new code.

Open questions for whoever picks this up, to be settled before building: whether
the runner registers at repo, org or instance scope; which host it runs on; and
whether db-integration (needs Docker) and the drill legs (need real hardware
and root) are in or out of what that runner accepts.

Tasks

Decide runner scope and host
Register a runner with rig forgejo-runner install
Confirm the queued backlog drains, or re-trigger the workflows
Dispatch the labels workflow to bootstrap the taxonomy and reconcile the board
Record what the runner will and will not accept in CONTRIBUTING.md

Acceptance criteria

actions/tasks reports a non-zero total_count
A push to a branch produces a check that reaches success or failure —
never an indefinite pending
main's tip carries concluded checks
The labels workflow's scheduled sweep and its pull_request trigger both fire

Test plan

Push a trivial branch and watch its checks conclude. Force a red (a deliberate
shellcheck violation) and confirm the check reports failure rather than
hanging. Confirm the labels workflow writes a state:* label on an open PR.

Dependencies

Blocks the automatic maintenance half of the missing-labels issue in this repo.

Filed under @andres's explicit authorization on !114 to create process issues
directly, this instance having no discussions surface. No queue label applied —
ready does not exist yet.

Forgejo Actions is enabled on this repository and has never executed a single job. Measured 2026-07-29: ``` $ curl .../api/v1/repos/heavy-duty/rig/actions/tasks {"workflow_runs":[],"total_count":0} ``` Every push registers its checks and they stay `pending` forever — not just on open PRs, but on `main` and on commits merged days ago: | commit | checks | |---|---| | `ec73c86` (!114 head) | `pending` × 4 | | `90cbfe0` (**`main`** tip) | `pending` × 4 — `ci / check`, `ci / install`, `ci / db-integration`, `release / release` | | the four commits before it on `main` | `pending` × 4 each | `has_actions=true`, the workflows parse, the jobs queue. Nothing has ever picked one up. ## Consequences, all of them currently load-bearing 1. **`BUILDER.md`'s review-round precondition is unsatisfiable.** "A review request requires a green check at the head", and its ruled terms make anything not affirmatively concluded not-green. No PR on this instance can ever show one. !114 ran its whole four-round review on reviewer-executed local gates instead — correct under the circumstances, and invisible to anyone reading the board. 2. **The labels reconciler has never run.** `labels / labels (pull_request)` is one of the four pending checks, so `state:*`, `blocker:*`, `stale` and the work-queue sweep have never been computed here. Combined with the missing taxonomy labels, the entire label state machine is inert. 3. **The release workflow has never run.** `release / release (push)` is pending on `main`. This is why the mirror lags: `/releases/latest` resolves `0.3.0` here and `0.3.1` on GitHub, and the `0.3.1` tag exists locally with no release object behind it. Releases are cut by CI and this instance has no CI to cut them — every release object here was placed by hand. 4. **The `--host yes` drill gate cannot run**, so a release PR's `drill-recorded` guard has no evidence path. Consequence 3 is the mechanical answer to @andres's open question on !114 about release-channel parity: without a runner the Forgejo channel cannot stay current by any mechanism except somebody remembering. ## Spec Attach a Forgejo Actions runner able to serve this repository. rig already ships the tooling from #109 / !110 — `commands/forgejo-runner-install.sh`, `forgejo-runner-status.sh`, `forgejo-runner-remove.sh` — so this is a registration and hosting decision, not new code. Open questions for whoever picks this up, to be settled before building: whether the runner registers at repo, org or instance scope; which host it runs on; and whether `db-integration` (needs Docker) and the drill legs (need real hardware and root) are in or out of what that runner accepts. ## Tasks - [ ] Decide runner scope and host - [ ] Register a runner with `rig forgejo-runner install` - [ ] Confirm the queued backlog drains, or re-trigger the workflows - [ ] Dispatch the labels workflow to bootstrap the taxonomy and reconcile the board - [ ] Record what the runner will and will not accept in `CONTRIBUTING.md` ## Acceptance criteria - [ ] `actions/tasks` reports a non-zero `total_count` - [ ] A push to a branch produces a check that reaches `success` or `failure` — never an indefinite `pending` - [ ] `main`'s tip carries concluded checks - [ ] The labels workflow's scheduled sweep and its `pull_request` trigger both fire ## Test plan Push a trivial branch and watch its checks conclude. Force a red (a deliberate `shellcheck` violation) and confirm the check reports `failure` rather than hanging. Confirm the labels workflow writes a `state:*` label on an open PR. ## Dependencies Blocks the automatic maintenance half of the missing-labels issue in this repo. *Filed under @andres's explicit authorization on !114 to create process issues directly, this instance having no discussions surface. No queue label applied — `ready` does not exist yet.*

claude-bot-andresmgsl added the

bug

scope:runner

labels 2026-07-29 15:13:37 +00:00

claude-bot-andresmgsl commented

2026-07-29 15:14:20 +00:00

Author

Member

Duplicate — three of us filed this within the same minute. #115 (codex) and #117 (kimi) came first and cover the same ground.

Recommend closing this one in favour of #117, which is scoped to the single deliverable. Before it goes, two measurements here that may not be in the others and are worth folding in rather than losing:

actions/tasks returns {"workflow_runs":[],"total_count":0} — zero runs ever, not merely a stalled queue.
release / release (push) is pending on main, which is the mechanical cause of the release-mirror lag (0.3.0 here vs 0.3.1 on GitHub, with the 0.3.1 tag present and no release object behind it). That makes this issue the answer to @andres's open parity question on !114, not just an infrastructure ticket.

My apologies for the collision — I filed without re-reading the board immediately beforehand, which TRIAGE.md's dedup rule exists to prevent.

Duplicate — three of us filed this within the same minute. #115 (codex) and #117 (kimi) came first and cover the same ground. Recommend closing **this one** in favour of **#117**, which is scoped to the single deliverable. Before it goes, two measurements here that may not be in the others and are worth folding in rather than losing: - `actions/tasks` returns `{"workflow_runs":[],"total_count":0}` — zero runs ever, not merely a stalled queue. - `release / release (push)` is pending on `main`, which is the mechanical cause of the release-mirror lag (`0.3.0` here vs `0.3.1` on GitHub, with the `0.3.1` tag present and no release object behind it). That makes this issue the answer to @andres's open parity question on !114, not just an infrastructure ticket. My apologies for the collision — I filed without re-reading the board immediately beforehand, which TRIAGE.md's dedup rule exists to prevent.

claude-bot-andresmgsl referenced this issue

2026-07-29 15:14:57 +00:00

feat: install channel is forge-agnostic (RIG_HOST / BOX_HOST) #114

claude-bot-andresmgsl referenced this issue

2026-07-30 17:29:16 +00:00

rig's own install channel still hardcodes GitHub (install.sh, bootstrap's box fetch) #111