feat(actions): add list_workflow_run_jobs and get_workflow_run_job_logs #126
No reviewers
Labels
No labels
Compat/Breaking
Kind/Bug
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/OpenSpec
Kind/Security
Kind/Testing
Priority/Critical
Priority/High
Priority/Low
Priority/Medium
RFC - Request For Comments
Reviewed/Confirmed
Reviewed/Duplicate
Reviewed/Invalid
Reviewed/Won't Fix
Status/Abandoned
Status/Blocked
Status/Need More Info
hermes-attempted
hermes-needs-clarification
hermes-ready
hermes-review
hermes-wip
human-required
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
agentic-forges/forgejo-mcp!126
Loading…
Reference in a new issue
No description provided.
Delete branch "refs/pull/126/head"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Problem
forgejo-mcpexposes 51 tools today but nothing for "show me what a CI job actually printed". Theactionsgroup covers run listing (list_workflow_runs), single-run details (get_workflow_run), and dispatching (dispatch_workflow), but to debug a failing run an LLM (or any caller) has to either render the run-page HTML and parse it or SSH to the Forgejo host and decompress*.log.zstby hand. Both are awkward and the second one is impossible for cloud-hosted instances.Change
Two new tools in
operation/actions/:list_workflow_run_jobswrapsGET /repos/{owner}/{repo}/actions/runs/{run_id}/jobs. That endpoint landed upstream in forgejo#11915 but isn't yet covered by the SDK we vendor (codeberg.org/mvdkleijn/forgejo-sdk/forgejo/v2).get_workflow_run_job_logswrapsGET /repos/{owner}/{repo}/actions/runs/{run_id}/jobs/{job_index}/logs. That endpoint is proposed upstream in forgejo#12508. The tool accepts an optionaltailparameter trimming output to the last N characters — Qt/Chromium-class logs can run to tens of MB and the diagnostic line is almost always at the end, so this keeps responses well below MCP's message size limit without needing a streaming protocol.Both tools bypass the SDK and issue plain HTTP against
flag.URLwith the sameflag.Tokenthe SDK uses, so they work on any Forgejo instance that exposes those routes (current dev branch / v16+ for jobs, fork-or-v16+-with-#12508 for logs). When the SDK gains coverage we should switch to the typed methods — see the comment at the top ofoperation/actions/jobs.go.Test plan
Manual against a Forgejo dev-branch instance carrying both endpoints:
Edge cases observed manually: nonexistent
run_idand out-of-rangejob_indexboth surface the upstream Forgejo 404 verbatim throughto.ErrorResult, which is what the LLM needs.Files touched
operation/actions/actions.go— register the two tools inRegisterTool.operation/actions/jobs.go— new file with both tool definitions, handlers, and a smallrawAPIRequesthelper for the SDK-bypass.No SDK bump, no other tool changes.
Assessment
Direction is right — debugging CI without log access is exactly the gap.
list_workflow_run_jobstargets the merged upstream endpoint (forgejo#11915, v16+) and is mergeable.get_workflow_run_job_logstargets the proposed endpoint (forgejo#12508, not yet merged); shipping a tool against unstable upstream surface risks rework or removal. PR also lacks automated tests despite the project'shttptest.Serverpatterns inpkg/forgejo/*_test.go, the newrawAPIRequesthelper duplicatespkg/forgejo.DoJSONList, and the README tool table is not updated. Thetailparameter overlaps with the uniform output-bounding policy tracked in #124 and should align with whatever naming lands there.Requested changes before merge
list_workflow_run_jobsnow. Deferget_workflow_run_job_logsuntil forgejo#12508 merges — don't ship against speculative upstream API surface.pkg/forgejo.DoJSONListinstead of the newrawAPIRequesthelper. Avoids two raw-HTTP code paths drifting (auth/UA/logging).pkg/forgejo/*_test.gohttptest.Serverstyle: happy path, 404,tailtruncation marker, out-of-rangejob_index.tailwith #124 policy. That issue is the umbrella for uniform output-bounding (line range, byte range, paging). Coordinate naming with whatever convention lands there (e.g.tail_bytes/max_bytes+ truncation marker rather than ambiguoustail).TODOreferencing the SDK issue.Verdict
Valid feature, accept after revisions. Splitting is mandatory; the rest is polish + alignment with the bounding policy in #124.
Follow-up to my earlier review: the bounding policy is now codified at
docs/design/output-bounding.mdand referenced fromAGENTS.md. Concrete asks for this PR using the checklist there:list_workflow_run_jobs— list-of-entities row in the parameter table: addpage+limitparameters; surfacetotal_countorhas_nextin the response so callers can resume.get_workflow_run_job_logs— log-stream row: renametail→tail_bytesper the parameter vocabulary; replace the existing free-text[truncated…]with a structured marker[truncated, N more bytes]so callers can tell exact tail position.AGENTS.md).No new requests beyond what's already in the original review — this is just the canonical reference to point at.
/test
op1st Pipelines as Code is skipping this commit.
User dmikushin is not allowed to trigger CI via pull_request_closed in this repo.
Pull request closed