coily ops forgejo: use HTTPS for all verbs, drop SSH #139

Open
opened 2026-05-28 07:58:33 +00:00 by coilysiren · 1 comment
Owner

Problem

Some coily ops forgejo verbs reach the Forgejo instance over SSH (in-pod
kubectl exec / SSH to kai-server) rather than the HTTP API. None of them should.
Every forgejo verb should use HTTPS against the Forgejo API.

Why

SSH-backed verbs fail in any session without an SSH key loaded into the agent.
Hit today: coily ops forgejo actions task logs returns

ssh: no authentication method available (ssh-agent unreachable and no key path)

because it does an in-pod log read over SSH to kai-server. This made CI logs
unreadable from a Claude session and blocked root-causing a release failure.
By contrast, issue create, release create/list, and actions task list
already work over HTTP from the same session - proving the HTTPS path is viable.

Scope

  • Audit every coily ops forgejo verb for SSH / kubectl exec dependence.
  • Convert each to the Forgejo HTTP API (token from SSM /forgejo/api-token,
    same auth pattern the working HTTP verbs already use).
  • Known offender: actions task logs (in-pod decoded-log read). The Forgejo
    Actions API exposes task logs over HTTP - use that instead of SSH.

Acceptance

  • No coily ops forgejo verb requires SSH or an in-pod exec.
  • actions task logs works from a session with no SSH key loaded.
  • Each converted verb authenticates via the SSM-stored API token over HTTPS.
## Problem Some `coily ops forgejo` verbs reach the Forgejo instance over SSH (in-pod `kubectl exec` / SSH to kai-server) rather than the HTTP API. None of them should. Every forgejo verb should use HTTPS against the Forgejo API. ## Why SSH-backed verbs fail in any session without an SSH key loaded into the agent. Hit today: `coily ops forgejo actions task logs` returns ``` ssh: no authentication method available (ssh-agent unreachable and no key path) ``` because it does an in-pod log read over SSH to kai-server. This made CI logs unreadable from a Claude session and blocked root-causing a release failure. By contrast, `issue create`, `release create/list`, and `actions task list` already work over HTTP from the same session - proving the HTTPS path is viable. ## Scope * Audit every `coily ops forgejo` verb for SSH / `kubectl exec` dependence. * Convert each to the Forgejo HTTP API (token from SSM `/forgejo/api-token`, same auth pattern the working HTTP verbs already use). * Known offender: `actions task logs` (in-pod decoded-log read). The Forgejo Actions API exposes task logs over HTTP - use that instead of SSH. ## Acceptance * No `coily ops forgejo` verb requires SSH or an in-pod exec. * `actions task logs` works from a session with no SSH key loaded. * Each converted verb authenticates via the SSM-stored API token over HTTPS.
Author
Owner

Scope: actions task logs converted; admin/doctor verbs deferred

Audited every coily ops forgejo verb against the live Forgejo 15.0.2 API.

Converted to HTTPS (this change)

  • actions task logs - was the motivating offender (in-pod cat | zstd -d
    over SSH). Forgejo's API v1 has no log endpoint, so it now drives the
    same web route the Actions UI uses:
    POST /{owner}/{repo}/actions/runs/{run}/jobs/{job}/attempt/{n} with a
    logCursors body, resolving the task id to its run+job by name and
    reassembling the per-step log lines. Works from a session with no SSH key.

Cannot convert - no HTTP API exists

  • doctor check - forgejo doctor is a CLI-only maintenance command. No API.
  • admin auth list - no auth-sources listing endpoint in the API.

These two have to stay on the in-pod forgejo CLI path (SSH / kubectl exec)
unless we drop the verbs entirely.

Convertible later (deferred)

  • admin user list - GET /admin/users exists; clean conversion, just not
    in scope for this pass.
  • admin user create - POST /admin/users exists but takes a password in the
    body. Today the verb uses in-pod --random-password so the secret never
    reaches coily's argv/audit log; converting changes that credential model and
    deserves its own discussion.

Proposal

Close this issue once actions task logs lands. Track admin user list
conversion as a small follow-up, and treat doctor check / admin auth list
as accepted SSH carve-outs (no API to convert to).

## Scope: `actions task logs` converted; admin/doctor verbs deferred Audited every `coily ops forgejo` verb against the live Forgejo 15.0.2 API. ### Converted to HTTPS (this change) * `actions task logs` - was the motivating offender (in-pod `cat | zstd -d` over SSH). Forgejo's API v1 has **no** log endpoint, so it now drives the same web route the Actions UI uses: `POST /{owner}/{repo}/actions/runs/{run}/jobs/{job}/attempt/{n}` with a `logCursors` body, resolving the task id to its run+job by name and reassembling the per-step log lines. Works from a session with no SSH key. ### Cannot convert - no HTTP API exists * `doctor check` - `forgejo doctor` is a CLI-only maintenance command. No API. * `admin auth list` - no auth-sources listing endpoint in the API. These two have to stay on the in-pod `forgejo` CLI path (SSH / kubectl exec) unless we drop the verbs entirely. ### Convertible later (deferred) * `admin user list` - `GET /admin/users` exists; clean conversion, just not in scope for this pass. * `admin user create` - `POST /admin/users` exists but takes a password in the body. Today the verb uses in-pod `--random-password` so the secret never reaches coily's argv/audit log; converting changes that credential model and deserves its own discussion. ### Proposal Close this issue once `actions task logs` lands. Track `admin user list` conversion as a small follow-up, and treat `doctor check` / `admin auth list` as accepted SSH carve-outs (no API to convert to).
coilysiren added
P2
and removed
P1
labels 2026-05-31 06:59:41 +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-bridge/coily#139
No description provided.