Forgejo Actions: find (or build) an API endpoint for action job/step logs #166

Open
opened 2026-05-28 09:32:43 +00:00 by coilysiren · 1 comment
Owner

Summary

There is no obvious token-authable /api/v1 endpoint to fetch the step logs (or even the job list) for a Forgejo Actions run. The web UI renders per-step logs fine, so the data exists. We need to find the right endpoint, and if one genuinely does not exist on this version, build a wrapper (or contribute upstream).

Context

Surfaced while verifying infrastructure#163 (cross-node flannel fix). A scheduled caddy-shortcuts -> regenerate run failed (run_number 112) and I wanted to pull its step log programmatically to characterize the failure. Could not, so the failure was diagnosed by elimination instead of by reading the log.

What works

  • GET /api/v1/repos/coilysiren/infrastructure/actions/runs/112 -> 200. Returns run metadata only. Keys: id, index_in_repo, status, workflow_id, html_url, event, trigger_event, trigger_user, commit_sha, started, stopped, .... No jobs array, no logs / log-download URL.
  • GET /api/v1/repos/coilysiren/infrastructure/actions/tasks?limit=N -> 200. Lists tasks (id, status, name, event, run_number, created_at). Also no per-task log link.

What returns 404

All probed against forgejo.coilysiren.me, Authorization: token </forgejo/api-token>:

  • /actions/runs/112/jobs
  • /actions/runs/138/jobs
  • /actions/tasks/138/logs
  • /actions/jobs/138/logs
  • /actions/jobs/138

Environment

  • Forgejo version: 15.0.2+gitea-1.22.0 (from GET /api/v1/version).

Asks / next steps

  • Confirm the correct /api/v1 path for Actions job logs on this Forgejo version (check the live swagger at /api/swagger, since the path/id type may differ from the GitHub convention, e.g. job id vs run_number vs task id).
  • If a token-authable endpoint exists: add a coily ops helper that fetches run/job step logs so agents can read CI failures directly.
  • If none exists on 15.0.2: decide between (a) a coily wrapper around the web route the UI uses, or (b) an upstream Forgejo contribution to expose job logs over /api/v1.

Relates to coilysiren/infrastructure#163.

## Summary There is no obvious token-authable `/api/v1` endpoint to fetch the step logs (or even the job list) for a Forgejo Actions run. The web UI renders per-step logs fine, so the data exists. We need to find the right endpoint, and if one genuinely does not exist on this version, build a wrapper (or contribute upstream). ## Context Surfaced while verifying infrastructure#163 (cross-node flannel fix). A scheduled `caddy-shortcuts` -> `regenerate` run failed (run_number 112) and I wanted to pull its step log programmatically to characterize the failure. Could not, so the failure was diagnosed by elimination instead of by reading the log. ## What works - `GET /api/v1/repos/coilysiren/infrastructure/actions/runs/112` -> 200. Returns run metadata only. Keys: `id, index_in_repo, status, workflow_id, html_url, event, trigger_event, trigger_user, commit_sha, started, stopped, ...`. No `jobs` array, no `logs` / log-download URL. - `GET /api/v1/repos/coilysiren/infrastructure/actions/tasks?limit=N` -> 200. Lists tasks (id, status, name, event, run_number, created_at). Also no per-task log link. ## What returns 404 All probed against `forgejo.coilysiren.me`, `Authorization: token <`/forgejo/api-token`>`: - `/actions/runs/112/jobs` - `/actions/runs/138/jobs` - `/actions/tasks/138/logs` - `/actions/jobs/138/logs` - `/actions/jobs/138` ## Environment - Forgejo version: `15.0.2+gitea-1.22.0` (from `GET /api/v1/version`). ## Asks / next steps - Confirm the correct `/api/v1` path for Actions job logs on this Forgejo version (check the live swagger at `/api/swagger`, since the path/id type may differ from the GitHub convention, e.g. job id vs run_number vs task id). - If a token-authable endpoint exists: add a `coily ops` helper that fetches run/job step logs so agents can read CI failures directly. - If none exists on 15.0.2: decide between (a) a `coily` wrapper around the web route the UI uses, or (b) an upstream Forgejo contribution to expose job logs over `/api/v1`. Relates to coilysiren/infrastructure#163.
Author
Owner

Checked the live swagger (/swagger.v1.json) on forgejo.coilysiren.me. Definitive result:

No logs endpoint exists in /api/v1 on this version. Zero paths in the whole spec contain the string log.

Full set of repo Actions endpoints in 15.0.2+gitea-1.22.0:

  • GET /repos/{owner}/{repo}/actions/runs - list runs
  • GET /repos/{owner}/{repo}/actions/runs/{run_id} - get one run (metadata only)
  • GET /repos/{owner}/{repo}/actions/tasks - list tasks
  • GET /repos/{owner}/{repo}/actions/runners/jobs - search jobs (filterable)

Correction to the issue body above: the job list is in fact reachable via GET /actions/runners/jobs (I had wrongly treated that as runner-only). So the gap is narrower than first stated: jobs are queryable, step/job logs are not. The web UI fetches logs over a non-/api/v1 web route.

Revised next step: this is a real API gap, not a wrong-path mistake. Options:

  1. coily wrapper around the web log route the UI uses (cookie/session auth), or
  2. upstream Forgejo contribution adding GET /repos/{owner}/{repo}/actions/jobs/{job_id}/logs to /api/v1.
Checked the live swagger (`/swagger.v1.json`) on `forgejo.coilysiren.me`. Definitive result: **No logs endpoint exists in `/api/v1` on this version.** Zero paths in the whole spec contain the string `log`. Full set of repo Actions endpoints in `15.0.2+gitea-1.22.0`: - `GET /repos/{owner}/{repo}/actions/runs` - list runs - `GET /repos/{owner}/{repo}/actions/runs/{run_id}` - get one run (metadata only) - `GET /repos/{owner}/{repo}/actions/tasks` - list tasks - `GET /repos/{owner}/{repo}/actions/runners/jobs` - search jobs (filterable) Correction to the issue body above: the **job list** is in fact reachable via `GET /actions/runners/jobs` (I had wrongly treated that as runner-only). So the gap is narrower than first stated: jobs are queryable, **step/job logs are not**. The web UI fetches logs over a non-`/api/v1` web route. Revised next step: this is a real API gap, not a wrong-path mistake. Options: 1. `coily` wrapper around the web log route the UI uses (cookie/session auth), or 2. upstream Forgejo contribution adding `GET /repos/{owner}/{repo}/actions/jobs/{job_id}/logs` to `/api/v1`.
coilysiren added
P4
and removed
P3
labels 2026-05-31 07:00:35 +00:00
Sign in to join this conversation.
No labels
P0
P1
P2
P3
P4
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/infrastructure#166
No description provided.