Add a generic tool to fetch full GitHub Actions log text (not just run status)

[proagentstore]

Problem

Today two tools report GitHub Actions run outcomes: agent_deploy_status (for ProAgentStore-hosted agent repos) and the coder's github_workflow_runs. Both call the GitHub Actions runs API and return status, conclusion, branch and a URL. Confirmed by reading the source directly (workers/api/src/lib/github-actions.ts, workers/api/src/lib/connectors/github.ts, workers/mcp/src/index.ts) that neither one, nor anything else in the repo, fetches the actual job/step log TEXT. github_workflow_runs was deliberately scoped as a separate read rather than a generalisation of agent_deploy_status (see comment at workers/mcp/src/coding-tools.ts:553-560), and issue #683's original scope was run status only.

Ask

Add a new read-only tool (e.g. github_workflow_run_logs or similar) that, given a repo and a run id (or job id), fetches the actual log content for that run/job — not just metadata — so the coder and chat can diagnose a failing step without a human pasting log text in. This should be generic: available to any repo the calling instance already has GitHub read access to, not special-cased to one store.

Constraints to consider before implementing

• GitHub's logs endpoint (GET /repos/{owner}/{repo}/actions/runs/{run_id}/logs and the per-job variant) returns a redirect to a zip of plain-text log files, not JSON — different fetch/parsing shape than the existing workflow_runs handler.
• Logs can be large; needs truncation/windowing similar to how repo_read_file already windows large files, rather than dumping the whole thing into a tool response.
• Confirm the GitHub App installation token already used for github_workflow_runs has the scope needed for the logs endpoint (Actions: read) — may already be covered, but verify rather than assume.
• Consider rate limits: log downloads are heavier than the runs-list call this reuses today.

Filed from a chat triage session after confirming via direct repo reads (not guessed) that this is a genuine gap, not an oversight in how an existing tool is being used.

[serge-ivo]

Shipped in 77ae29c as github_workflow_run_logs on the GitHub connector, granted to coder-repo and tmux-coder (migration 0148). Two notes where the build departs from the issue's constraint list, each checked against code or the API before deciding:

1. Per job, not per run — so there is no zip. The issue's first constraint describes …/runs/{run_id}/logs, which does answer with a zip archive a Worker would have to parse. The per-job endpoint …/jobs/{job_id}/logs answers with a redirect to a single plain-text file, and a job is the unit a failure lives in anyway. The tool lists the run's jobs, picks the first failed one (else the running one, else the last), and reads that. Its header names every job with its job_id and the steps that did not succeed, so a caller asks for a different job by id.

2. The token is verified to cover it, not assumed. The tool mints through the same connectorClient("github").token() path as github_workflow_runs. Listing runs on a private repo needs the App's Actions read permission; downloading a job log needs the same permission. So if runs work on a repo today, logs do, with no new scope. The redirect is followed with redirect:"manual" and a second fetch that carries a deadline and nothing else, so the installation token never reaches the blob host.

The other two constraints are met as asked: logs are windowed by line with renderRepoFileWindow (the same helper repo_read_file uses), read from the END by default since that is where the failure is, with the exact continuation call in the header; and cost is bounded to one job per call with a 2MB cap that keeps the tail.

Also stripped: GitHub's per-line timestamp prefix (29 characters a line), stated in the header, so a 20,000-character window holds roughly twice the log lines.