Fix Forgejo Actions log bridge for PR job status targets #425

New issue

Closed

opened 2026-07-10 09:44:32 +00:00 by coilyco-ops · 2 comments

coilyco-ops commented

2026-07-10 09:44:32 +00:00

Member

Problem

During review of agentic-os#423, Forgejo exposed a failed PR status target:

context: ci / gate (pull_request)
status: failure
target_url: /coilyco-flight-deck/agentic-os/actions/runs/886/jobs/0

The committed log bridge in .ward/forgejo-actions-logs.sh documents and calls:

/api/v1/repos/{owner}/{repo}/actions/runs/{run}/jobs/{job}/attempt/{attempt}/logs

But the current bridge route returns 404 for the visible PR job target:

.ward/forgejo-actions-logs.sh coilyco-flight-deck agentic-os 886 0 1
curl: (22) The requested URL returned error: 404

Tried variants using run number 886, task id 8733, and /jobs/0/logs; they also return 404. The HTML run and job pages are reachable, so this is a bridge/API route mismatch, not lack of access.

This is narrower than agentic-os#415, which tracks replacing the bash bridge with a ward fetch overlay. This issue is the immediate usability repair: when a PR status points at an Actions job, the operator/director needs a working plaintext log command.

Acceptance criteria

The bridge can fetch logs for a PR status target like /actions/runs/886/jobs/0, or it prints a precise diagnostic explaining the unsupported route and the next usable command.
Docs show how to map a Forgejo status target_url to the log command inputs.
Tests cover the route/argument mapping for PR job status targets.
The bridge continues to preserve token auth and owner/repo gating.
The larger ward fetch-overlay replacement remains tracked separately by agentic-os#415.

## Problem During review of `agentic-os#423`, Forgejo exposed a failed PR status target: ```text context: ci / gate (pull_request) status: failure target_url: /coilyco-flight-deck/agentic-os/actions/runs/886/jobs/0 ``` The committed log bridge in `.ward/forgejo-actions-logs.sh` documents and calls: ```text /api/v1/repos/{owner}/{repo}/actions/runs/{run}/jobs/{job}/attempt/{attempt}/logs ``` But the current bridge route returns 404 for the visible PR job target: ```text .ward/forgejo-actions-logs.sh coilyco-flight-deck agentic-os 886 0 1 curl: (22) The requested URL returned error: 404 ``` Tried variants using run number `886`, task id `8733`, and `/jobs/0/logs`; they also return 404. The HTML run and job pages are reachable, so this is a bridge/API route mismatch, not lack of access. This is narrower than `agentic-os#415`, which tracks replacing the bash bridge with a ward fetch overlay. This issue is the immediate usability repair: when a PR status points at an Actions job, the operator/director needs a working plaintext log command. ## Acceptance criteria * The bridge can fetch logs for a PR status target like `/actions/runs/886/jobs/0`, or it prints a precise diagnostic explaining the unsupported route and the next usable command. * Docs show how to map a Forgejo status `target_url` to the log command inputs. * Tests cover the route/argument mapping for PR job status targets. * The bridge continues to preserve token auth and owner/repo gating. * The larger ward fetch-overlay replacement remains tracked separately by `agentic-os#415`.

coilyco-ops added the

headless

labels

2026-07-10 09:44:32 +00:00

coilyco-ops commented

2026-07-10 09:44:43 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

Holder: container engineer-codex-agentic-os-425 on host kais-macbook-pro-2.local.

Reserved by ward agent --harness codex (reserved 2026-07-10T09:44:42Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (1h 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/agentic-os#425 · branch issue-425 · harness codex · workflow pull-requests-and-merge
Run: engineer-codex-agentic-os-425 · ward v0.569.0 · dispatched 2026-07-10T09:44:42Z
Comment thread: 0 included in the pre-flight read, 0 stripped (ward's own automated comments).

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

— Codex, via ward agent

WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-agentic-os-425` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-10T09:44:42Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (1h 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/agentic-os#425` · branch `issue-425` · harness `codex` · workflow `pull-requests-and-merge` - **Run:** `engineer-codex-agentic-os-425` · ward `v0.569.0` · dispatched `2026-07-10T09:44:42Z` - **Comment thread:** 0 included in the pre-flight read, 0 stripped (ward's own automated comments). Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.569.0). </details> </details>  — Codex, via `ward agent`

coilyco-ops referenced this issue from a pull request that will close it,

2026-07-10 09:57:02 +00:00

Fix Forgejo Actions log bridge for PR job status targets #429

coilyco-ops closed this issue

2026-07-10 09:59:13 +00:00

coilyco-ops commented

2026-07-10 09:59:47 +00:00

Author

Member

WARD-OUTCOME: merge-ready

details

workflow: pull-requests-and-merge, review summary: skipped because review gate skipped by ~/.ward/config.yaml default
felt: straightforward after the status target to job-id mapping surfaced in the live HTML
confidence: high
surprises: Forgejo exposes run index and job index in the target_url, but the logs route needs internal run id and job id
follow-ups: none

WARD-OUTCOME: merge-ready <details><summary>details</summary> workflow: pull-requests-and-merge, review summary: skipped because review gate skipped by ~/.ward/config.yaml default felt: straightforward after the status target to job-id mapping surfaced in the live HTML confidence: high surprises: Forgejo exposes run index and job index in the target_url, but the logs route needs internal run id and job id follow-ups: none </details>