rasterstate/fj

Watch

Fork 0

Retrieve Actions logs on private repos (token-accepting path or cookie/CSRF auth) #103

New issue

Open

opened 2026-06-10 23:49:52 +00:00 by stephen · 3 comments

stephen commented

2026-06-10 23:49:52 +00:00

Owner

What

Make fj run view <n> --log/--log-failed actually retrieve step logs on private repos. Today the only working log path is the Forgejo web frontend route under /{owner}/{repo}/actions/runs/{run}/jobs/{job}/attempt/{attempt} (see the module header in src/api/workflow_view.rs), which authenticates with a session cookie + CSRF token, not an API token. On a private repo that route 404s under token auth, so logs are unreadable through fj.

Find a path that works under the credentials fj actually holds (an API token in the OS keychain). Options, roughly in order of preference:

A token-accepting /api/v1 Actions log endpoint, if the target Forgejo version exposes one. rasterstate/fj#91 reports that on the observed Forgejo (11.0.x / gitea-1.22 era) /api/v1/.../actions/runs/{n}/jobs, /api/v1/.../actions/jobs/{id}/logs, and /api/v1/.../actions/runs/{n}/logs all 404, so this may simply not exist there. Re-verify per version before building on it.
Cookie/CSRF auth against the web log route: obtain a session and CSRF token (e.g. via a stored browser cookie or an interactive login) and replay them on the existing web-route requests. This is a second auth path and must not bypass Client::request / is_trusted_url casually; design it deliberately.
If neither is available on a given Forgejo, document the limitation and point users at the fallback (/actions/tasks for pass/fail, web UI for logs).

Why

fj run view --log is the primary way to read CI output without leaving the terminal, and most of our repos are private (rasterstate/fjord-ios, rasterstate/flux, ...). rasterstate/fj#91 and its duplicate rasterstate/fj#92 both hit this during real CI triage and had to fall back to the /actions/tasks API for pass/fail and to server-side sqlite (action_task_step.log_length) for ground truth. The error-message fix in rasterstate/fj#91 stops the misdiagnosis, but it does not restore the feature: private-repo logs still cannot be read through fj.

Acceptance

fj run view <n> --log and --log-failed print real step logs for a private repo run that has logs, against a Forgejo version where a supported path exists.
The chosen auth path funnels through Client::request and respects is_trusted_url (no second, unguarded HTTP/credential path).
If no token-accepting or cookie path is viable on a given Forgejo version, the limitation is documented (docs/troubleshooting) and the actionable error from rasterstate/fj#91 names the fallback.
Coverage for the working path (wiremock for a token-accepting endpoint, or an equivalent test for the cookie path).
cargo fmt --check, cargo clippy --all-targets --all-features -- -D warnings, cargo test --all pass.

Dependencies

Builds on rasterstate/fj#91 (the error-message + private-repo-detection slice). That ships first and is independent; this item restores the capability.
Uncertain / parked: blocked on confirming whether the target Forgejo version exposes ANY token-accepting Actions-log endpoint. rasterstate/fj#91 suggests it may not, in which case this becomes cookie/CSRF auth or a documented limitation rather than a typed API wrapper. Do not start until that contract is pinned down for a concrete Forgejo version.

Out of scope

The error-message / auth-vs-missing distinction and its private-repo test (rasterstate/fj#91).
Public-repo log retrieval, which already works through the web route.

Size

L (uncertain; may reduce to "document the limitation" if no auth path exists)

## What Make `fj run view <n> --log/--log-failed` actually retrieve step logs on **private** repos. Today the only working log path is the Forgejo **web** frontend route under `/{owner}/{repo}/actions/runs/{run}/jobs/{job}/attempt/{attempt}` (see the module header in `src/api/workflow_view.rs`), which authenticates with a **session cookie + CSRF token**, not an API token. On a private repo that route 404s under token auth, so logs are unreadable through `fj`. Find a path that works under the credentials `fj` actually holds (an API token in the OS keychain). Options, roughly in order of preference: 1. A token-accepting `/api/v1` Actions log endpoint, if the target Forgejo version exposes one. rasterstate/fj#91 reports that on the observed Forgejo (11.0.x / gitea-1.22 era) `/api/v1/.../actions/runs/{n}/jobs`, `/api/v1/.../actions/jobs/{id}/logs`, and `/api/v1/.../actions/runs/{n}/logs` all 404, so this may simply not exist there. Re-verify per version before building on it. 2. Cookie/CSRF auth against the web log route: obtain a session and CSRF token (e.g. via a stored browser cookie or an interactive login) and replay them on the existing web-route requests. This is a second auth path and must not bypass `Client::request` / `is_trusted_url` casually; design it deliberately. 3. If neither is available on a given Forgejo, document the limitation and point users at the fallback (`/actions/tasks` for pass/fail, web UI for logs). ## Why `fj run view --log` is the primary way to read CI output without leaving the terminal, and most of our repos are private (rasterstate/fjord-ios, rasterstate/flux, ...). rasterstate/fj#91 and its duplicate rasterstate/fj#92 both hit this during real CI triage and had to fall back to the `/actions/tasks` API for pass/fail and to server-side sqlite (`action_task_step.log_length`) for ground truth. The error-message fix in rasterstate/fj#91 stops the misdiagnosis, but it does not restore the feature: private-repo logs still cannot be read through `fj`. ## Acceptance - [ ] `fj run view <n> --log` and `--log-failed` print real step logs for a **private** repo run that has logs, against a Forgejo version where a supported path exists. - [ ] The chosen auth path funnels through `Client::request` and respects `is_trusted_url` (no second, unguarded HTTP/credential path). - [ ] If no token-accepting or cookie path is viable on a given Forgejo version, the limitation is documented (docs/troubleshooting) and the actionable error from rasterstate/fj#91 names the fallback. - [ ] Coverage for the working path (wiremock for a token-accepting endpoint, or an equivalent test for the cookie path). - [ ] `cargo fmt --check`, `cargo clippy --all-targets --all-features -- -D warnings`, `cargo test --all` pass. ## Dependencies - Builds on rasterstate/fj#91 (the error-message + private-repo-detection slice). That ships first and is independent; this item restores the capability. - **Uncertain / parked:** blocked on confirming whether the target Forgejo version exposes ANY token-accepting Actions-log endpoint. rasterstate/fj#91 suggests it may not, in which case this becomes cookie/CSRF auth or a documented limitation rather than a typed API wrapper. Do not start until that contract is pinned down for a concrete Forgejo version. ## Out of scope - The error-message / auth-vs-missing distinction and its private-repo test (rasterstate/fj#91). - Public-repo log retrieval, which already works through the web route. ## Size L (uncertain; may reduce to "document the limitation" if no auth path exists)

stephen added the

backlog

parked

labels

2026-06-10 23:50:02 +00:00

stephen referenced this issue

2026-06-10 23:50:28 +00:00

fj run view: distinguish private-repo log auth failure from a missing run, instead of masking it as "no logs" #91

stephen commented

2026-06-11 02:30:23 +00:00

Author

Owner

Product-validation + feasibility: private-repo Actions log retrieval

Posting this as the operator-facing decision record for this parked item. Two parts: (1) is the pain worth the work, and (2) if so, by which path. TL;DR up front: the acute pain is already cured by rasterstate/fj#91, the remaining pain is a recurring papercut, and the only client-side path (cookie/CSRF) costs far more than the papercut. Pursue a server-side/gateway endpoint and an upstream request instead; keep this parked behind the shipped documented-limitation.

1. Product validation

Who needs it, and how often. This is a real, recurring need, not a hypothetical. fj run watch / fj run view --log is the headline reason to use fj over the web UI at all: read CI output without leaving the terminal. Most of our repos are private (rasterstate/fjord-ios, rasterstate/flux, and the rest), so "private-repo logs" is not an edge case, it is the common case for anyone triaging CI here. Frequency tracks how often private-repo CI goes red and someone wants the log in-terminal, which for active repos is daily-ish. So on raw frequency this scores high.

The cost of today's fallback. After rasterstate/fj#91 shipped, the fallback is three layers, and they are better than they sound:

The rasterstate/fj#91 actionable error. This is the important one. The original failure mode was not "I have to open a browser," it was silent misdiagnosis: every run, green or red, returned no logs for that run/job/attempt, which reads as "the job died before producing logs." rasterstate/fj#92 documents that exact error sending a triage on a multi-step detour through runner provisioning and autoscaler limits for what was an ordinary step failure whose logs existed the whole time. rasterstate/fj#91 replaced that with a message that names the real cause (web log route rejects token auth; private-repo logs need session auth) and points here. That converts a wrong answer into a correct "go look in the web UI" signpost. The expensive part of the pain (chasing a nonexistent cause) is already gone.
The web UI. One click to the run page gives full, rendered logs. It works today on every private repo. The cost is leaving the terminal, a papercut, not a blocker.
The token-accessible /actions/tasks list. Still readable under the PAT, so fj run list and pass/fail status work in-terminal on private repos. You lose the log body, not run state.

Does the pain justify the work? Honest read: the remaining pain is a recurring papercut, not a fire, and it does not justify an expensive fix. Two of our own issues (rasterstate/fj#91, rasterstate/fj#92) were filed from real CI triage that this blocked, which is genuine evidence the feature matters, but both predate the rasterstate/fj#91 error fix. The thing that actually hurt (misdiagnosis) is cured. What's left is "on a private repo, --log can't print the body, click through to the web UI instead," correctly signposted. That justifies a cheap fix (an upstream ask, or a server-side endpoint we get nearly for free) and the already-shipped documentation. It does not justify forking the auth model to chase it. The work is only worth doing if the path is cheap.

2. Feasibility

Technical baseline (re-confirmed against the code). src/api/workflow_view.rs is explicit that /api/v1 exposes no Actions log surface: single-run, per-run /jobs, /jobs/{id}/logs, and /runs/{id}/logs all 404. Both the run summary and the logs live only behind the human web routes under /{owner}/{repo}/actions/.... On a public repo those routes answer a token-bearing request; on a private repo they 404 because they want a session cookie + CSRF token, not a PAT. So the only client-side path to private logs is to authenticate as the browser does.

What browser-session auth concretely requires. This is a second, heavier auth system, not a tweak:

Login flow. POST the Forgejo login form (user + password) to mint a session cookie. fj auth login today prompts for a PAT and stores one opaque string per host (src/auth/mod.rs). Cookie auth means prompting for a password, a regression in credential hygiene (PATs are scoped and revocable; a password is not).
CSRF fetch. Scrape the _csrf token from a form/meta tag or cookie and replay it on every state-changing web request. Brittle, tied to the HTML, unversioned.
Cookie jar. reqwest is currently used statelessly through one Client::request; we'd add cookie-store handling and a parallel notion of "logged-in session" alongside the token.
Secure session storage. The session cookie is a bearer credential and would have to live in the keychain next to the PAT, doubling the secret surface (src/auth/mod.rs deliberately stores only tokens, never to disk).
2FA. Accounts with TOTP/WebAuthn can't be driven by a form POST without an interactive second-factor dance. There is no clean headless story.
Session expiry / refresh. Sessions expire server-side on Forgejo's schedule. We'd need to detect expiry, re-prompt, and silently re-login, ongoing complexity the PAT model never has.

Security + maintenance burden. High and permanent. We'd be storing a second class of credential, prompting for passwords, parsing CSRF out of HTML, and depending on unversioned web routes plus a login form that upstream can restyle or re-auth at any release, with no API contract. The module header already flags these routes as "stable in practice but can shift between Forgejo releases." Every one of those shifts becomes a fj-breaks-on-upgrade incident. For a papercut-sized payoff, this is a bad trade.

Alternatives, ranked.

Upstream Forgejo token-log endpoint request (do this first; cheapest). File an issue/PR upstream asking for a token-accepting /api/v1/.../actions/jobs/{id}/logs (or equivalent). If it lands, fj deletes the whole web-route hack and private logs become an ordinary typed /api/v1 wrapper, the cleanest possible end state. Cost to us is a writeup; risk is timeline (not ours to control). Low effort, high upside, no downside, so it's worth filing regardless of what else we do.
Paragon / server-side gateway log endpoint (the real fix if we build anything). We already run the piece that makes this natural: src/fjord/mod.rs shows Fjord-Account traffic routing through fjord-platform's /api/v1/forge-gateway/:instance-id/api/v1/..., and the platform already performs a credentialed sign-in (it even handles a 2FA recovery code). Crucially, workflow_view.rs notes the gateway only proxies /api/v1, so it doesn't forward the web log routes today, which is exactly the gap. The server side can hold the session (or read action_task_step.log_length / the log blobs directly, the same ground truth rasterstate/fj#91 and rasterstate/fj#92 had to reach via sqlite) and expose a clean token-or-bearer log endpoint that fj calls like any other gateway route. This keeps all the session/CSRF/2FA/expiry burden server-side where it's already solved, instead of shipping it to every client. Effort is real but bounded, and it only helps Fjord-Account users (PAT-direct users still need option 1 or the web UI). This is where to invest if the papercut proves worth investing in.
Document as limitation (the current state; keep it). rasterstate/fj#91 already shipped: the actionable error names session-vs-token auth and links here, and /actions/tasks still gives in-terminal pass/fail. Add a troubleshooting note ("private-repo log bodies aren't retrievable via PAT; use the web UI or a Fjord-Account instance") and this is a defensible resting state indefinitely.

Recommendation

Do not build client-side cookie/CSRF auth. It forks the auth model (passwords, cookie jar, CSRF scraping, 2FA, expiry, second keychain secret) against unversioned web routes, a permanent maintenance and security tax, to fix a papercut that rasterstate/fj#91 already de-fanged.

Instead:

File the upstream Forgejo token-log-endpoint request now (option 1). Cheap, and it's the only path that fully removes the hack.
Keep this item parked behind the rasterstate/fj#91 documented-limitation, which is the correct resting state today (option 3). Land the small troubleshooting-doc note if it isn't already in.
Only promote to active work as a server-side gateway endpoint (option 2), and only when private-repo log triage is demonstrably costing more than the per-incident web-UI click, i.e. when this papercut starts drawing blood again. If/when it does, the gateway is the place to build it, not the client.

No production code written and no labels changed here; leaving the parked/backlog state for you to set.

## Product-validation + feasibility: private-repo Actions log retrieval Posting this as the operator-facing decision record for this parked item. Two parts: (1) is the pain worth the work, and (2) if so, by which path. TL;DR up front: the acute pain is already cured by rasterstate/fj#91, the remaining pain is a recurring papercut, and the only client-side path (cookie/CSRF) costs far more than the papercut. Pursue a server-side/gateway endpoint and an upstream request instead; keep this parked behind the shipped documented-limitation. --- ### 1. Product validation **Who needs it, and how often.** This is a real, recurring need, not a hypothetical. `fj run watch` / `fj run view --log` is the headline reason to use `fj` over the web UI at all: read CI output without leaving the terminal. Most of our repos are private (rasterstate/fjord-ios, rasterstate/flux, and the rest), so "private-repo logs" is not an edge case, it is the common case for anyone triaging CI here. Frequency tracks how often private-repo CI goes red and someone wants the log in-terminal, which for active repos is daily-ish. So on raw frequency this scores high. **The cost of today's fallback.** After rasterstate/fj#91 shipped, the fallback is three layers, and they are better than they sound: - **The rasterstate/fj#91 actionable error.** This is the important one. The original failure mode was not "I have to open a browser," it was *silent misdiagnosis*: every run, green or red, returned `no logs for that run/job/attempt`, which reads as "the job died before producing logs." rasterstate/fj#92 documents that exact error sending a triage on a multi-step detour through runner provisioning and autoscaler limits for what was an ordinary step failure whose logs existed the whole time. rasterstate/fj#91 replaced that with a message that names the real cause (web log route rejects token auth; private-repo logs need session auth) and points here. That converts a wrong answer into a correct "go look in the web UI" signpost. The expensive part of the pain (chasing a nonexistent cause) is already gone. - **The web UI.** One click to the run page gives full, rendered logs. It works today on every private repo. The cost is leaving the terminal, a papercut, not a blocker. - **The token-accessible `/actions/tasks` list.** Still readable under the PAT, so `fj run list` and pass/fail status work in-terminal on private repos. You lose the *log body*, not run state. **Does the pain justify the work?** Honest read: **the remaining pain is a recurring papercut, not a fire, and it does not justify an expensive fix.** Two of our own issues (rasterstate/fj#91, rasterstate/fj#92) were filed from real CI triage that this blocked, which is genuine evidence the feature matters, but both predate the rasterstate/fj#91 error fix. The thing that actually hurt (misdiagnosis) is cured. What's left is "on a private repo, `--log` can't print the body, click through to the web UI instead," correctly signposted. That justifies a *cheap* fix (an upstream ask, or a server-side endpoint we get nearly for free) and the already-shipped documentation. It does **not** justify forking the auth model to chase it. The work is only worth doing if the path is cheap. --- ### 2. Feasibility **Technical baseline (re-confirmed against the code).** `src/api/workflow_view.rs` is explicit that `/api/v1` exposes no Actions log surface: single-run, per-run `/jobs`, `/jobs/{id}/logs`, and `/runs/{id}/logs` all 404. Both the run summary and the logs live only behind the human web routes under `/{owner}/{repo}/actions/...`. On a **public** repo those routes answer a token-bearing request; on a **private** repo they 404 because they want a session cookie + CSRF token, not a PAT. So the only client-side path to private logs is to authenticate as the browser does. **What browser-session auth concretely requires.** This is a second, heavier auth system, not a tweak: - **Login flow.** POST the Forgejo login form (user + password) to mint a session cookie. `fj auth login` today prompts for a PAT and stores one opaque string per host (`src/auth/mod.rs`). Cookie auth means prompting for a *password*, a regression in credential hygiene (PATs are scoped and revocable; a password is not). - **CSRF fetch.** Scrape the `_csrf` token from a form/meta tag or cookie and replay it on every state-changing web request. Brittle, tied to the HTML, unversioned. - **Cookie jar.** `reqwest` is currently used statelessly through one `Client::request`; we'd add cookie-store handling and a parallel notion of "logged-in session" alongside the token. - **Secure session storage.** The session cookie is a bearer credential and would have to live in the keychain next to the PAT, doubling the secret surface (`src/auth/mod.rs` deliberately stores only tokens, never to disk). - **2FA.** Accounts with TOTP/WebAuthn can't be driven by a form POST without an interactive second-factor dance. There is no clean headless story. - **Session expiry / refresh.** Sessions expire server-side on Forgejo's schedule. We'd need to detect expiry, re-prompt, and silently re-login, ongoing complexity the PAT model never has. **Security + maintenance burden.** High and permanent. We'd be storing a second class of credential, prompting for passwords, parsing CSRF out of HTML, and depending on **unversioned** web routes plus a login form that upstream can restyle or re-auth at any release, with no API contract. The module header already flags these routes as "stable in practice but can shift between Forgejo releases." Every one of those shifts becomes a `fj`-breaks-on-upgrade incident. For a papercut-sized payoff, this is a bad trade. **Alternatives, ranked.** 1. **Upstream Forgejo token-log endpoint request (do this first; cheapest).** File an issue/PR upstream asking for a token-accepting `/api/v1/.../actions/jobs/{id}/logs` (or equivalent). If it lands, `fj` deletes the whole web-route hack and private logs become an ordinary typed `/api/v1` wrapper, the cleanest possible end state. Cost to us is a writeup; risk is timeline (not ours to control). Low effort, high upside, no downside, so it's worth filing regardless of what else we do. 2. **Paragon / server-side gateway log endpoint (the real fix if we build anything).** We already run the piece that makes this natural: `src/fjord/mod.rs` shows Fjord-Account traffic routing through fjord-platform's `/api/v1/forge-gateway/:instance-id/api/v1/...`, and the platform already performs a credentialed `sign-in` (it even handles a 2FA recovery code). Crucially, `workflow_view.rs` notes the gateway only proxies `/api/v1`, so it **doesn't** forward the web log routes today, which is exactly the gap. The server side can hold the session (or read `action_task_step.log_length` / the log blobs directly, the same ground truth rasterstate/fj#91 and rasterstate/fj#92 had to reach via sqlite) and expose a clean token-or-bearer log endpoint that `fj` calls like any other gateway route. This keeps all the session/CSRF/2FA/expiry burden server-side where it's already solved, instead of shipping it to every client. Effort is real but bounded, and it only helps Fjord-Account users (PAT-direct users still need option 1 or the web UI). This is where to invest *if* the papercut proves worth investing in. 3. **Document as limitation (the current state; keep it).** rasterstate/fj#91 already shipped: the actionable error names session-vs-token auth and links here, and `/actions/tasks` still gives in-terminal pass/fail. Add a troubleshooting note ("private-repo log bodies aren't retrievable via PAT; use the web UI or a Fjord-Account instance") and this is a defensible resting state indefinitely. --- ### Recommendation **Do not build client-side cookie/CSRF auth.** It forks the auth model (passwords, cookie jar, CSRF scraping, 2FA, expiry, second keychain secret) against unversioned web routes, a permanent maintenance and security tax, to fix a papercut that rasterstate/fj#91 already de-fanged. Instead: - **File the upstream Forgejo token-log-endpoint request now** (option 1). Cheap, and it's the only path that fully removes the hack. - **Keep this item parked** behind the rasterstate/fj#91 documented-limitation, which is the correct resting state today (option 3). Land the small troubleshooting-doc note if it isn't already in. - **Only promote to active work as a server-side gateway endpoint** (option 2), and only when private-repo log triage is demonstrably costing more than the per-incident web-UI click, i.e. when this papercut starts drawing blood again. If/when it does, the gateway is the place to build it, not the client. No production code written and no labels changed here; leaving the parked/backlog state for you to set.

stephen commented

2026-07-14 20:31:27 +00:00

Author

Owner

Contract pinned: no token-accepting Actions-log endpoint on Forgejo 15.0.3

This issue was parked on: "blocked on confirming whether the target Forgejo version exposes ANY token-accepting Actions-log endpoint... Do not start until that contract is pinned down for a concrete Forgejo version." Pinning it now.

The prior negative observation (#91, #92) was made on Forgejo 11.0.x / gitea-1.22 era. The live instance has since moved to 15.0.3+gitea-1.22.0 (GET /api/v1/version), so that result could not simply be carried forward across four majors of drift. It had to be re-probed.

Method: read the running server's own OpenAPI spec, which is authoritative for what the binary actually serves:

curl -s https://rasterhub.com/swagger.v1.json | jq -r '.paths | keys[] | select(test("actions|logs"))'

Every Actions path the live server declares:

GET  /repos/{owner}/{repo}/actions/runs                        -> ListActionRuns
GET  /repos/{owner}/{repo}/actions/runs/{run_id}               -> ActionRun
GET  /repos/{owner}/{repo}/actions/tasks                       -> ListActionTasks
POST /repos/{owner}/{repo}/actions/workflows/{file}/dispatches -> DispatchWorkflow
     ... plus runners / secrets / variables CRUD

Findings

No log endpoint exists. There is no /actions/jobs/{job_id}/logs, no /actions/runs/{run_id}/logs, and no /actions/runs/{run_id}/jobs. Option (1) in this issue is confirmed dead on 15.0.3 -- not "may not exist", but does not exist.
No rerun/cancel endpoint either. Filtering the whole spec for rerun|retry|cancel|approve returns only DispatchWorkflow, which fires a fresh workflow_dispatch (not a rerun of an existing run, and only for workflows that opt into that trigger). Relevant to rasterstate/fleet#178, whose acceptance includes rerunning a failed run.
New since 11.0.x: ActionRun and ListActionRuns are now typed API endpoints. They give run-level metadata/status under token auth, but no step log content.

Consequence

This issue resolves to option (2) (cookie/CSRF session auth against the web log route) or option (3) (document the limitation). It does not reduce to a typed API wrapper.

The "Size: L (uncertain)" uncertainty is now removed: the uncertainty was entirely about whether (1) existed, and it does not. The blocker in Dependencies is cleared and this is ready to start.

Recommend proceeding with (2), scoped exactly as the acceptance criteria already require: the session path must funnel through Client::request and respect is_trusted_url, rather than opening a second unguarded HTTP/credential path.

## Contract pinned: no token-accepting Actions-log endpoint on Forgejo 15.0.3 This issue was parked on: *"blocked on confirming whether the target Forgejo version exposes ANY token-accepting Actions-log endpoint... Do not start until that contract is pinned down for a concrete Forgejo version."* Pinning it now. The prior negative observation (#91, #92) was made on **Forgejo 11.0.x / gitea-1.22 era**. The live instance has since moved to **15.0.3+gitea-1.22.0** (`GET /api/v1/version`), so that result could not simply be carried forward across four majors of drift. It had to be re-probed. **Method:** read the running server's own OpenAPI spec, which is authoritative for what the binary actually serves: ``` curl -s https://rasterhub.com/swagger.v1.json | jq -r '.paths | keys[] | select(test("actions|logs"))' ``` **Every Actions path the live server declares:** ``` GET /repos/{owner}/{repo}/actions/runs -> ListActionRuns GET /repos/{owner}/{repo}/actions/runs/{run_id} -> ActionRun GET /repos/{owner}/{repo}/actions/tasks -> ListActionTasks POST /repos/{owner}/{repo}/actions/workflows/{file}/dispatches -> DispatchWorkflow ... plus runners / secrets / variables CRUD ``` ### Findings 1. **No log endpoint exists.** There is no `/actions/jobs/{job_id}/logs`, no `/actions/runs/{run_id}/logs`, and no `/actions/runs/{run_id}/jobs`. **Option (1) in this issue is confirmed dead on 15.0.3** -- not "may not exist", but *does not exist*. 2. **No rerun/cancel endpoint either.** Filtering the whole spec for `rerun|retry|cancel|approve` returns only `DispatchWorkflow`, which fires a fresh `workflow_dispatch` (not a rerun of an existing run, and only for workflows that opt into that trigger). Relevant to `rasterstate/fleet#178`, whose acceptance includes rerunning a failed run. 3. **New since 11.0.x:** `ActionRun` and `ListActionRuns` are now typed API endpoints. They give run-level metadata/status under token auth, but no step log content. ### Consequence This issue resolves to **option (2)** (cookie/CSRF session auth against the web log route) or **option (3)** (document the limitation). It does **not** reduce to a typed API wrapper. The "Size: L (uncertain)" uncertainty is now removed: the uncertainty was entirely about whether (1) existed, and it does not. The blocker in **Dependencies** is cleared and this is ready to start. Recommend proceeding with (2), scoped exactly as the acceptance criteria already require: the session path must funnel through `Client::request` and respect `is_trusted_url`, rather than opening a second unguarded HTTP/credential path.

stephen referenced this issue

2026-07-30 00:34:29 +00:00

release: make a failed tag release recoverable, and fix the generated Homebrew formula #233

stephen referenced this issue

2026-07-30 01:04:41 +00:00

Release v0.4.1 shipped with zero artifacts, so brew installs 0.3.0 on GA day #232

stephen referenced this issue from a commit

2026-08-04 18:30:34 +00:00

Probe the runner toolchain to establish why unit-tests is red (temporary)

lane-claude-2 referenced this issue from a commit

2026-08-08 05:16:53 +00:00

BISECT PROBE: disable the flag-lifted sshd cases for one CI run

lane-claude-3 referenced this issue

2026-08-09 04:34:25 +00:00

gpg_key_verify 500s on ed25519 keys (RSA verifies fine), with an empty error message #244

stephen commented

2026-08-09 20:04:05 +00:00

Author

Owner

This conclusion is wrong, and it has been costing us CI diagnosis for weeks. An API token does read Actions logs. There are two working endpoints; fj is using neither.

Measured today on rasterhub.com (Forgejo 16.0.2, fj 0.4.1), with an ordinary API token and no browser session:

GET /api/v1/repos/{owner}/{repo}/actions/jobs/{job_id}/logs
  -> 200, 61402 bytes, plain text, the complete job log

GET /api/v1/repos/{owner}/{repo}/actions/runs/{run_id}/logs
  -> 200, application/zip, one entry per job

The zip case, on a real run:

Length      Name
1194520     gate-12502-attempt-1.log
1397231     build-core-12503-attempt-1.log
  85649     build-admin-12504-attempt-1.log
     30     deploy-12505-attempt-1.MISSING

.MISSING entries carry the body job has not been executed yet, so the format even distinguishes "no log" from "never ran", which is exactly the distinction we have been unable to make from the outside.

What fj does instead

fj run view --log-failed and fj run rerun both fail with the message this issue records:

$ fj run rerun 5359 --repo rasterstate/paragon --failed
error: cannot read logs for run #5359: the Forgejo web log route rejected API
token auth. Log retrieval on private repos needs a browser session
(cookie/CSRF); an API token is not accepted by this route.

The premise is accurate about the web route and false as a general claim. fj run rerun is worse off than fj run view, because it reads logs as a precondition for an operation that does not need them, so a working rerun is blocked by a broken log path.

Why this matters beyond convenience

fleet#267 has eight occurrences of paragon CI jobs dying mid-compile, and every investigation round has ended at "the job output is not retrievable through the API path". That was never true. The most recent round spent a full lane session concluding it from this issue's premise, and the negative result it produced is sound but was reached the long way.

Suggested fix

fj run log / fj run view --log* use /actions/runs/{id}/logs (zip, all jobs) or /actions/jobs/{id}/logs (single job) with token auth. Both accept the same token fj already holds.
fj run rerun stops reading logs entirely. It does not need them.
Note for whoever picks this up: this Forgejo has no rerun API endpoint. POST /actions/runs/{id}/rerun and /actions/jobs/{id}/rerun both 404, so rerun may need to stay a web-route operation. That is a separate question from log access and should not be conflated again.

This conclusion is wrong, and it has been costing us CI diagnosis for weeks. **An API token does read Actions logs.** There are two working endpoints; fj is using neither. Measured today on rasterhub.com (Forgejo 16.0.2, fj 0.4.1), with an ordinary API token and no browser session: ``` GET /api/v1/repos/{owner}/{repo}/actions/jobs/{job_id}/logs -> 200, 61402 bytes, plain text, the complete job log GET /api/v1/repos/{owner}/{repo}/actions/runs/{run_id}/logs -> 200, application/zip, one entry per job ``` The zip case, on a real run: ``` Length Name 1194520 gate-12502-attempt-1.log 1397231 build-core-12503-attempt-1.log 85649 build-admin-12504-attempt-1.log 30 deploy-12505-attempt-1.MISSING ``` `.MISSING` entries carry the body `job has not been executed yet`, so the format even distinguishes "no log" from "never ran", which is exactly the distinction we have been unable to make from the outside. ## What fj does instead `fj run view --log-failed` and `fj run rerun` both fail with the message this issue records: ``` $ fj run rerun 5359 --repo rasterstate/paragon --failed error: cannot read logs for run #5359: the Forgejo web log route rejected API token auth. Log retrieval on private repos needs a browser session (cookie/CSRF); an API token is not accepted by this route. ``` The premise is accurate about the **web** route and false as a general claim. `fj run rerun` is worse off than `fj run view`, because it reads logs as a precondition for an operation that does not need them, so a working rerun is blocked by a broken log path. ## Why this matters beyond convenience fleet#267 has eight occurrences of paragon CI jobs dying mid-compile, and every investigation round has ended at "the job output is not retrievable through the API path". That was never true. The most recent round spent a full lane session concluding it from this issue's premise, and the negative result it produced is sound but was reached the long way. ## Suggested fix 1. `fj run log` / `fj run view --log*` use `/actions/runs/{id}/logs` (zip, all jobs) or `/actions/jobs/{id}/logs` (single job) with token auth. Both accept the same token fj already holds. 2. `fj run rerun` stops reading logs entirely. It does not need them. 3. Note for whoever picks this up: this Forgejo has no rerun API endpoint. `POST /actions/runs/{id}/rerun` and `/actions/jobs/{id}/rerun` both 404, so rerun may need to stay a web-route operation. That is a separate question from log access and should not be conflated again.