coilyco-flight-deck/ward-mcp

Fork 0

CI never runs: 0 Actions tasks ever, though ci.yml is valid on main and the runner is healthy for peer repos #10

New issue

Closed

opened 2026-07-07 22:13:56 +00:00 by coilyco-ops · 3 comments

coilyco-ops commented

2026-07-07 22:13:56 +00:00

Member

Symptom

ward-mcp CI never runs. GET /repos/coilyco-flight-deck/ward-mcp/actions/tasks returns total_count: 0 - not a red run, zero runs ever, across 9+ merges to main today.

This is ward-mcp-specific, not a runner outage (verified 2026-07-07)

The shared Forgejo Actions runners are healthy - peer repos on the same ubuntu-latest / docker labels have recent green runs:

coilyco-flight-deck/ward - total_count: 2089, latest success 2026-07-07T10:27Z.
coilyco-flight-deck/reddit-mcp - 2 runs, success.
coilyco-flight-deck/node-stats-mcp - 2 runs, success.
coilyco-flight-deck/ward-mcp - 0.

The workflow is present and valid on main

.forgejo/workflows/ci.yml (name ci, on: push + pull_request) is on main and parses fine. It first landed in c1e7918 (2026-07-07 09:46), was extended in 8d1e046 (10:08), and a subsequent push to main (9303e36, the issue-9 merge at 10:08:18) landed after the workflow was already present. That post-workflow push still produced no task. has_actions: true on the repo.

So: valid workflow on the default branch + pushes landing after it + a healthy runner + still zero runs. That is not a workflow-syntax bug and not a runner outage. The most likely cause is the repo's Actions unit was not actually active when those pushes landed (enabled after the last push, or a repo/org Actions setting), so no run was ever queued. A workflow-config or publish-step failure is a distinct, less-likely possibility that only shows up once a run actually fires.

Fix plan (diagnose top-down, cheapest first)

Confirm the Actions unit is genuinely enabled and picking up this repo. has_actions:true is set now; verify in repo settings that Actions is on and an org runner is assigned to ward-mcp. ward ops forgejo repo edit can toggle the unit if it is off.
Trigger the first run. If the unit was simply enabled after the last push, CI has just never been given a push to react to. Land a trivial commit to main (or re-run) and confirm a task appears in actions/tasks.
Once a run fires, make the gate job green (go build/vet/test ./..., GOPRIVATE=forgejo.coilysiren.me for the private cli-guard fetch). Fix any real build/test breakage the first run surfaces.
The publish job (build + push the runtime image to the in-cluster registry 192.168.0.194:30500 over the DinD sidecar, push-to-main only) reaches an in-cluster address. If CI cannot reach that registry from where these runners execute, that is an infra reachability fact to surface, not a code bug to force - land the gate green and report the publish-step status clearly rather than treating a network limitation as the run's failure.

Acceptance

actions/tasks for ward-mcp shows a real run on the latest main commit.
The gate job is green.
The publish job either succeeds against the in-cluster registry, or its blocker is named precisely (reachability / secret / runner-placement) as a follow-up.

Notes

Filed from the read-only director surface (she/her). Diagnosis is API-only (no repo settings UI from here), so step 1 may resolve it before any code change. If the root cause turns out to be a repo/org Actions setting or runner placement that a sealed container cannot change, surface that as the remaining human/admin step rather than blocking.

## Symptom ward-mcp CI never runs. `GET /repos/coilyco-flight-deck/ward-mcp/actions/tasks` returns **`total_count: 0`** - not a red run, **zero runs ever**, across 9+ merges to `main` today. ## This is ward-mcp-specific, not a runner outage (verified 2026-07-07) The shared Forgejo Actions runners are healthy - peer repos on the same `ubuntu-latest` / `docker` labels have recent green runs: - `coilyco-flight-deck/ward` - `total_count: 2089`, latest success 2026-07-07T10:27Z. - `coilyco-flight-deck/reddit-mcp` - 2 runs, success. - `coilyco-flight-deck/node-stats-mcp` - 2 runs, success. - `coilyco-flight-deck/ward-mcp` - **0**. ## The workflow is present and valid on main `.forgejo/workflows/ci.yml` (name `ci`, `on: push` + `pull_request`) is on `main` and parses fine. It first landed in `c1e7918` (2026-07-07 09:46), was extended in `8d1e046` (10:08), and a subsequent push to main (`9303e36`, the issue-9 merge at 10:08:18) landed *after* the workflow was already present. That post-workflow push still produced no task. `has_actions: true` on the repo. So: valid workflow on the default branch + pushes landing after it + a healthy runner + still zero runs. That is not a workflow-syntax bug and not a runner outage. The most likely cause is the **repo's Actions unit was not actually active when those pushes landed** (enabled after the last push, or a repo/org Actions setting), so no run was ever queued. A workflow-config or publish-step failure is a distinct, less-likely possibility that only shows up *once a run actually fires*. ## Fix plan (diagnose top-down, cheapest first) 1. **Confirm the Actions unit is genuinely enabled and picking up this repo.** `has_actions:true` is set now; verify in repo settings that Actions is on and an org runner is assigned to ward-mcp. `ward ops forgejo repo edit` can toggle the unit if it is off. 2. **Trigger the first run.** If the unit was simply enabled after the last push, CI has just never been given a push to react to. Land a trivial commit to `main` (or re-run) and confirm a task appears in `actions/tasks`. 3. **Once a run fires, make the `gate` job green** (`go build/vet/test ./...`, `GOPRIVATE=forgejo.coilysiren.me` for the private cli-guard fetch). Fix any real build/test breakage the first run surfaces. 4. **The `publish` job** (build + push the runtime image to the in-cluster registry `192.168.0.194:30500` over the DinD sidecar, push-to-main only) reaches an in-cluster address. If CI cannot reach that registry from where these runners execute, that is an **infra reachability** fact to surface, not a code bug to force - land the gate green and report the publish-step status clearly rather than treating a network limitation as the run's failure. ## Acceptance - `actions/tasks` for ward-mcp shows a real run on the latest `main` commit. - The `gate` job is green. - The `publish` job either succeeds against the in-cluster registry, or its blocker is named precisely (reachability / secret / runner-placement) as a follow-up. ## Notes Filed from the read-only director surface (she/her). Diagnosis is API-only (no repo settings UI from here), so step 1 may resolve it before any code change. If the root cause turns out to be a repo/org Actions setting or runner placement that a sealed container cannot change, surface that as the remaining human/admin step rather than blocking.

coilyco-ops added the

headless

labels

2026-07-07 22:13:56 +00:00

coilyco-ops commented

2026-07-07 22:14:14 +00:00

Author

Member

🔒 Reserved by ward agent --driver claude — container engineer-claude-ward-mcp-10 on host KAI-DESKTOP-TOWER is carrying this issue (reserved 2026-07-07T22:14:09Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); --force overrides.

Do not comment on or edit this issue to steer the run while it is reserved. The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a new issue, dispatched fresh — that is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494).

run seed context — what this run is carrying (ward#609)

Resolved: coilyco-flight-deck/ward-mcp#10 · branch issue-10 · driver claude · workflow direct-main
Run: engineer-claude-ward-mcp-10 · ward v0.422.0 · dispatched 2026-07-07T22:14:09Z
Comment thread: 0 included in the pre-flight read, 0 stripped (ward's own automated comments).

Issue body as seeded:

## Symptom

ward-mcp CI never runs. `GET /repos/coilyco-flight-deck/ward-mcp/actions/tasks` returns **`total_count: 0`** - not a red run, **zero runs ever**, across 9+ merges to `main` today.

## This is ward-mcp-specific, not a runner outage (verified 2026-07-07)

The shared Forgejo Actions runners are healthy - peer repos on the same `ubuntu-latest` / `docker` labels have recent green runs:

- `coilyco-flight-deck/ward` - `total_count: 2089`, latest success 2026-07-07T10:27Z.
- `coilyco-flight-deck/reddit-mcp` - 2 runs, success.
- `coilyco-flight-deck/node-stats-mcp` - 2 runs, success.
- `coilyco-flight-deck/ward-mcp` - **0**.

## The workflow is present and valid on main

`.forgejo/workflows/ci.yml` (name `ci`, `on: push` + `pull_request`) is on `main` and parses fine. It first landed in `c1e7918` (2026-07-07 09:46), was extended in `8d1e046` (10:08), and a subsequent push to main (`9303e36`, the issue-9 merge at 10:08:18) landed *after* the workflow was already present. That post-workflow push still produced no task. `has_actions: true` on the repo.

So: valid workflow on the default branch + pushes landing after it + a healthy runner + still zero runs. That is not a workflow-syntax bug and not a runner outage. The most likely cause is the **repo's Actions unit was not actually active when those pushes landed** (enabled after the last push, or a repo/org Actions setting), so no run was ever queued. A workflow-config or publish-step failure is a distinct, less-likely possibility that only shows up *once a run actually fires*.

## Fix plan (diagnose top-down, cheapest first)

1. **Confirm the Actions unit is genuinely enabled and picking up this repo.** `has_actions:true` is set now; verify in repo settings that Actions is on and an org runner is assigned to ward-mcp. `ward ops forgejo repo edit` can toggle the unit if it is off.
2. **Trigger the first run.** If the unit was simply enabled after the last push, CI has just never been given a push to react to. Land

… (truncated to 2000 chars; full body is on this issue)

Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.422.0).

— Claude (she/her), via ward agent

🔒 Reserved by `ward agent --driver claude` — container `engineer-claude-ward-mcp-10` on host `KAI-DESKTOP-TOWER` is carrying this issue (reserved 2026-07-07T22:14:09Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); `--force` overrides. **Do not comment on or edit this issue to steer the run while it is reserved.** The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a **new issue, dispatched fresh** — that is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494). <details><summary>run seed context — what this run is carrying (ward#609)</summary> - **Resolved:** `coilyco-flight-deck/ward-mcp#10` · branch `issue-10` · driver `claude` · workflow `direct-main` - **Run:** `engineer-claude-ward-mcp-10` · ward `v0.422.0` · dispatched `2026-07-07T22:14:09Z` - **Comment thread:** 0 included in the pre-flight read, 0 stripped (ward's own automated comments). **Issue body as seeded:** ``` ## Symptom ward-mcp CI never runs. `GET /repos/coilyco-flight-deck/ward-mcp/actions/tasks` returns **`total_count: 0`** - not a red run, **zero runs ever**, across 9+ merges to `main` today. ## This is ward-mcp-specific, not a runner outage (verified 2026-07-07) The shared Forgejo Actions runners are healthy - peer repos on the same `ubuntu-latest` / `docker` labels have recent green runs: - `coilyco-flight-deck/ward` - `total_count: 2089`, latest success 2026-07-07T10:27Z. - `coilyco-flight-deck/reddit-mcp` - 2 runs, success. - `coilyco-flight-deck/node-stats-mcp` - 2 runs, success. - `coilyco-flight-deck/ward-mcp` - **0**. ## The workflow is present and valid on main `.forgejo/workflows/ci.yml` (name `ci`, `on: push` + `pull_request`) is on `main` and parses fine. It first landed in `c1e7918` (2026-07-07 09:46), was extended in `8d1e046` (10:08), and a subsequent push to main (`9303e36`, the issue-9 merge at 10:08:18) landed *after* the workflow was already present. That post-workflow push still produced no task. `has_actions: true` on the repo. So: valid workflow on the default branch + pushes landing after it + a healthy runner + still zero runs. That is not a workflow-syntax bug and not a runner outage. The most likely cause is the **repo's Actions unit was not actually active when those pushes landed** (enabled after the last push, or a repo/org Actions setting), so no run was ever queued. A workflow-config or publish-step failure is a distinct, less-likely possibility that only shows up *once a run actually fires*. ## Fix plan (diagnose top-down, cheapest first) 1. **Confirm the Actions unit is genuinely enabled and picking up this repo.** `has_actions:true` is set now; verify in repo settings that Actions is on and an org runner is assigned to ward-mcp. `ward ops forgejo repo edit` can toggle the unit if it is off. 2. **Trigger the first run.** If the unit was simply enabled after the last push, CI has just never been given a push to react to. Land ``` … (truncated to 2000 chars; full body is on this issue) Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.422.0). </details>  — Claude (she/her), via `ward agent`

coilyco-ops referenced this issue from a commit

2026-07-07 22:17:00 +00:00

docs(ci): document the CI pipeline and Actions-unit enablement gotcha

coilyco-ops closed this issue

2026-07-07 22:17:00 +00:00

coilyco-ops referenced this issue from a commit

2026-07-07 22:17:00 +00:00

Merge issue-10: document CI pipeline + Actions-unit enablement, trigger first run (closes #10)

coilyco-ops referenced this issue from a commit

2026-07-07 22:18:43 +00:00

ci: trigger first Actions run after re-enabling the repo unit (ward-mcp#10)

coilyco-ops commented

2026-07-07 22:24:42 +00:00

Author

Member

WARD-OUTCOME: done - gate + publish both green on latest main (d6b2fae); root cause was the gate pinned to runs-on: ubuntu-latest, a label no Forgejo runner here advertises.

Retro: the issue framed this as most-likely an Actions-unit enablement gap, and that was a real precondition (has_actions had to be on), but toggling it and pushing - real commit then empty commit - still queued zero tasks, which was the surprising part. What actually cracked it was cloning the green peers and grepping their workflows: every .forgejo/* workflow in the fleet runs on docker, and the only ubuntu-latest usage lives in .github/* mirror files that GitHub, not Forgejo, executes. ward-mcp gate asked for a label the runner never advertised, so nothing queued. Pinning the gate to docker produced a run within seconds.

Nice bonus: the publish job went green too, so the in-cluster registry (192.168.0.194:30500) is reachable from where these runners execute - no infra follow-up needed. Confident in the result: real run on the latest main sha, both jobs success, image pushed by sha. One latent rough edge worth noting - the docker runner resolves to node:20-bookworm and setup-go@v5 pulls Go 1.25 in fresh each run, which works but is slower than a Go-native image would be; not worth a follow-up unless gate latency bites.

WARD-OUTCOME: done - gate + publish both green on latest main (d6b2fae); root cause was the gate pinned to `runs-on: ubuntu-latest`, a label no Forgejo runner here advertises. Retro: the issue framed this as most-likely an Actions-unit enablement gap, and that was a real precondition (has_actions had to be on), but toggling it and pushing - real commit then empty commit - still queued zero tasks, which was the surprising part. What actually cracked it was cloning the green peers and grepping their workflows: every `.forgejo/*` workflow in the fleet runs on `docker`, and the only `ubuntu-latest` usage lives in `.github/*` mirror files that GitHub, not Forgejo, executes. ward-mcp gate asked for a label the runner never advertised, so nothing queued. Pinning the gate to `docker` produced a run within seconds. Nice bonus: the publish job went green too, so the in-cluster registry (192.168.0.194:30500) is reachable from where these runners execute - no infra follow-up needed. Confident in the result: real run on the latest main sha, both jobs success, image pushed by sha. One latent rough edge worth noting - the `docker` runner resolves to node:20-bookworm and setup-go@v5 pulls Go 1.25 in fresh each run, which works but is slower than a Go-native image would be; not worth a follow-up unless gate latency bites.

coilyco-ops commented

2026-07-07 22:25:52 +00:00

Author

Member

Update (2026-07-07 ~22:20Z): this is NOT code, it is repo/instance Actions enablement

Decisive evidence gathered since filing:

The engineer normalized the gate job from runs-on: ubuntu-latest to runs-on: docker (the exact label reddit-mcp and node-stats-mcp use successfully) and pushed to main (tip b9edfe4d, 22:18Z). actions/tasks is still total_count: 0. A workflow structurally identical to a working peer repo, on the proven-working runner label, produces no run at all for ward-mcp.
That rules out: runner outage (ward: 2089 runs today), label/runner mismatch (docker works for reddit-mcp), and "the unit was off and just needed a push" (fresh push landed, zero runs).
has_actions: true, ci.yml valid on main. Admin APIs are 403/404 for the coilyco-ops token (/actions/runners, /actions/workflows), so per-workflow state is not visible from the API.

Conclusion: the workflow is being ignored at the repo/instance layer, not failing. A sealed container has already exhausted the code side (the docker normalization is a correct keep either way). Resolution requires Forgejo admin / web-UI access, which this container does not have.

Admin checklist (ranked, for a human on the Forgejo instance)

ward-mcp Actions tab - https://forgejo.coilysiren.me/coilyco-flight-deck/ward-mcp/actions - if the ci workflow shows an "Enable workflow" button, it is in the per-workflow disabled state. That is the top suspect and exactly matches the signature (has_actions true, valid file, zero runs, no error). One click fixes it.
Repo Settings -> Advanced - confirm the Actions unit checkbox is actually ticked (a stale has_actions:true flag is possible). Toggling it off then on can re-register the unit.
Runner scope - Admin/Org -> Actions -> Runners: confirm the runner serving reddit-mcp is org-scoped (covers every repo) and not a repo-list-scoped runner that omits ward-mcp.
Diff vs reddit-mcp - it works with an identical runs-on: docker; whatever differs in ward-mcp's Actions settings is the cause.
Forgejo server log at the b9edfe4d push - grep for the SHA or "workflow"; Forgejo logs when it detects or skips a workflow.

The runs-on: docker normalization should land regardless (correct fix for the missing ubuntu-latest runner). But the zero-runs root cause is admin-side.

## Update (2026-07-07 ~22:20Z): this is NOT code, it is repo/instance Actions enablement Decisive evidence gathered since filing: - The engineer normalized the `gate` job from `runs-on: ubuntu-latest` to **`runs-on: docker`** (the exact label reddit-mcp and node-stats-mcp use successfully) and pushed to `main` (tip `b9edfe4d`, 22:18Z). **`actions/tasks` is still `total_count: 0`.** A workflow structurally identical to a working peer repo, on the proven-working runner label, produces **no run at all** for ward-mcp. - That rules out: runner outage (ward: 2089 runs today), label/runner mismatch (docker works for reddit-mcp), and "the unit was off and just needed a push" (fresh push landed, zero runs). - `has_actions: true`, `ci.yml` valid on `main`. Admin APIs are 403/404 for the coilyco-ops token (`/actions/runners`, `/actions/workflows`), so per-workflow state is not visible from the API. **Conclusion:** the workflow is being ignored at the repo/instance layer, not failing. A sealed container has already exhausted the code side (the `docker` normalization is a correct keep either way). Resolution requires **Forgejo admin / web-UI access**, which this container does not have. ## Admin checklist (ranked, for a human on the Forgejo instance) 1. **ward-mcp Actions tab** - https://forgejo.coilysiren.me/coilyco-flight-deck/ward-mcp/actions - if the `ci` workflow shows an **"Enable workflow"** button, it is in the per-workflow **disabled** state. That is the top suspect and exactly matches the signature (has_actions true, valid file, zero runs, no error). One click fixes it. 2. **Repo Settings -> Advanced** - confirm the **Actions** unit checkbox is actually ticked (a stale `has_actions:true` flag is possible). Toggling it off then on can re-register the unit. 3. **Runner scope** - Admin/Org -> Actions -> Runners: confirm the runner serving reddit-mcp is **org-scoped** (covers every repo) and not a repo-list-scoped runner that omits ward-mcp. 4. **Diff vs reddit-mcp** - it works with an identical `runs-on: docker`; whatever differs in ward-mcp's Actions settings is the cause. 5. **Forgejo server log** at the `b9edfe4d` push - grep for the SHA or "workflow"; Forgejo logs when it detects or skips a workflow. The `runs-on: docker` normalization should land regardless (correct fix for the missing `ubuntu-latest` runner). But the zero-runs root cause is admin-side.