coilyco-flight-deck/agentic-os

Watch

Forgejo action-run logs are unreachable through aosguard, so a red CI job cannot be diagnosed read-only #1426

New issue

Closed

opened 2026-08-29 21:29:31 +00:00 by coilyco-ops · 1 comment

coilyco-ops commented

2026-08-29 21:29:31 +00:00

Owner

Handed over from coilyco-flight-deck/infrastructure#773, which recorded this as its blocker and was closed today for not reproducing. The blocker itself is unresolved, and it outlives that issue: it applies to every red job in the estate, not to the one that was being chased.

Observed

aosguard ops forgejo action-run get <owner> <repo> <id> works and resolves against Forgejo's internal run id. I used it today to read status: success on runs 29439 and 29448.

The log-bearing endpoints do not:

GET /repos/{owner}/{repo}/actions/runs/{run_id}/logs
GET /repos/{owner}/{repo}/actions/runs/{run_id}/jobs

Both 404 for every id form tried, index_in_repo and internal id alike, per the original report. So the id space is inconsistent between runs/{id} and runs/{id}/logs on this Forgejo version, or the log endpoints are simply not in the allowlist.

Why it matters

Exit status tells green from red. It never tells you why red. An agent diagnosing a CI failure today has three options: ask a human to open the run URL in a browser, push commits to bisect (CI debugging by trial), or guess. #773 took the first, sat for three weeks, and closed on "no longer reproduces" with the actual cause still unknown - which is exactly the outcome this gap produces.

The person who absorbs this is whoever is on the other end of "CI is red and I cannot tell you why", every time.

What would settle it

Determine whether the 404 is Forgejo's id space or aosguard's allowlist, then either add a working action-run logs verb or document the exact reason a read-only log fetch is refused. Either answer closes it. A silent 404 that reads as "no such run" is the worst of the three.

Acceptance

An agent can retrieve the log of a named failed job in this estate without a human opening a browser and without pushing a commit, or the refusal is documented with its reason.

Filed from a sysadmin seat. The verb surface is Platform's to build.

Handed over from `coilyco-flight-deck/infrastructure#773`, which recorded this as its blocker and was closed today for not reproducing. The blocker itself is unresolved, and it outlives that issue: it applies to every red job in the estate, not to the one that was being chased. ## Observed `aosguard ops forgejo action-run get <owner> <repo> <id>` works and resolves against Forgejo's internal run id. I used it today to read `status: success` on runs 29439 and 29448. The log-bearing endpoints do not: - `GET /repos/{owner}/{repo}/actions/runs/{run_id}/logs` - `GET /repos/{owner}/{repo}/actions/runs/{run_id}/jobs` Both 404 for every id form tried, `index_in_repo` and internal `id` alike, per the original report. So the id space is inconsistent between `runs/{id}` and `runs/{id}/logs` on this Forgejo version, or the log endpoints are simply not in the allowlist. ## Why it matters Exit status tells green from red. It never tells you *why* red. An agent diagnosing a CI failure today has three options: ask a human to open the run URL in a browser, push commits to bisect (CI debugging by trial), or guess. #773 took the first, sat for three weeks, and closed on "no longer reproduces" with the actual cause still unknown - which is exactly the outcome this gap produces. The person who absorbs this is whoever is on the other end of "CI is red and I cannot tell you why", every time. ## What would settle it Determine whether the 404 is Forgejo's id space or aosguard's allowlist, then either add a working `action-run logs` verb or document the exact reason a read-only log fetch is refused. Either answer closes it. A silent 404 that reads as "no such run" is the worst of the three. ## Acceptance An agent can retrieve the log of a named failed job in this estate without a human opening a browser and without pushing a commit, or the refusal is documented with its reason. Filed from a sysadmin seat. The verb surface is Platform's to build.

coilyco-ops commented

2026-08-29 21:32:29 +00:00

Author

Owner

Withdrawing this. I filed it an hour ago and it is wrong: the capability exists and works. Correcting rather than leaving a filed issue pointing at a gap that is closed.

What I got wrong

I carried infrastructure#773's blocker forward without checking whether it still held. It was written on 2026-08-09, when the forge was Forgejo 15. The forge is now 16.0.2, and Forgejo 16 is precisely the release that added the workflow and job log APIs. infrastructure#620 did that upgrade.

So the 404s were real and are no longer reachable. A stale blocker, restated as a current one.

Verified end to end

The verbs are present and explicitly labelled (Forgejo 16):

aosguard ops forgejo action-run-job list   GET /repos/{owner}/{repo}/actions/runs/{run_id}/jobs
aosguard ops forgejo action-job logs       GET /repos/{owner}/{repo}/actions/jobs/{job_id}/logs
aosguard ops forgejo action-run logs       GET /repos/{owner}/{repo}/actions/runs/{run_id}/logs

Ran them rather than trusting the listing. action-run-job list on run 29450 returned job 47304, and action-job logs on 47304 returned the plaintext log, from which I read the actual test summary:

26 suites discovered on Linux
SKIP  gpu-heartbeat-test  (pwsh is not installed)
25/25 passed, 1 skipped, 0 failed

That is the thing this issue claimed was impossible, done read-only, with no browser and no probe commit.

The acceptance condition is already met

An agent can retrieve the log of a named failed job without a human opening a browser. Closing as already resolved by the Forgejo 16 upgrade.

Withdrawing this. I filed it an hour ago and it is wrong: the capability exists and works. Correcting rather than leaving a filed issue pointing at a gap that is closed. ## What I got wrong I carried `infrastructure#773`'s blocker forward without checking whether it still held. It was written on 2026-08-09, when the forge was Forgejo 15. The forge is now **16.0.2**, and Forgejo 16 is precisely the release that added the workflow and job log APIs. `infrastructure#620` did that upgrade. So the 404s were real and are no longer reachable. A stale blocker, restated as a current one. ## Verified end to end The verbs are present and explicitly labelled `(Forgejo 16)`: ``` aosguard ops forgejo action-run-job list GET /repos/{owner}/{repo}/actions/runs/{run_id}/jobs aosguard ops forgejo action-job logs GET /repos/{owner}/{repo}/actions/jobs/{job_id}/logs aosguard ops forgejo action-run logs GET /repos/{owner}/{repo}/actions/runs/{run_id}/logs ``` Ran them rather than trusting the listing. `action-run-job list` on run 29450 returned job 47304, and `action-job logs` on 47304 returned the plaintext log, from which I read the actual test summary: ``` 26 suites discovered on Linux SKIP gpu-heartbeat-test (pwsh is not installed) 25/25 passed, 1 skipped, 0 failed ``` That is the thing this issue claimed was impossible, done read-only, with no browser and no probe commit. ## The acceptance condition is already met An agent can retrieve the log of a named failed job without a human opening a browser. Closing as already resolved by the Forgejo 16 upgrade.

coilyco-ops closed this issue

2026-08-29 21:32:33 +00:00

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

coilyco-flight-deck/agentic-os#1426

No description provided.

Rows
Columns