Route trusted Linux builds to managed runners - #508
Conversation
Same-repository branches are controlled by repository collaborators and should use organization capacity, while fork pull requests remain arbitrary code. Main-branch reusable workflows make that trust decision enforceable even when a fork edits its own workflow files. Generated with Codex Co-authored-by: Codex <noreply@openai.com>
roborev: Combined Review (
|
pull_request_target associates validation with the base commit, so it cannot reliably gate updates to a same-repository PR. Use ordinary pull_request dispatchers and keep the runner trust decision inside the main-pinned reusable workflows, where both head and base repository identities must match before selecting the managed fleet. Generated with Codex Co-authored-by: Codex <noreply@openai.com>
roborev: Combined Review (
|
Bind managed runner selection to the canonical repository and use the immutable pull request event SHA, so forks fall back to hosted runners and checks cannot drift to a newer merge ref. Lint proposed workflow revisions on hosted infrastructure before merge. Assisted-by: OpenAI
roborev: Combined Review (
|
Let the reusable workflow derive its checkout target directly from the caller event instead of accepting a ref from the pull request-controlled dispatcher. This removes the remaining caller-controlled input at the runner trust boundary and keeps each check tied to the revision GitHub associated with the run. Generated with Codex Co-authored-by: Codex <noreply@openai.com>
roborev: Combined Review (
|
|
false positive |
|
This finding is a false positive under the runner policy currently enforced by GitHub. The runner group that provides
A fork can rewrite This would become a real vulnerability if the group stopped being restricted to selected workflows, if a PR-ref dispatcher were added to the allowlist, or if the same label were exposed through another unrestricted runner group. None of those conditions is present. |
Three consecutive main builds (aaba110, a8b4f4b, 930a891) failed in test-postgres and test-pgvector after #508 routed trusted Linux jobs to the managed public fleet. Both die on Go's default 10m per-package timeout in cmd/msgvault/cmd, and it is not a hung test: each failure has a different test in flight when the alarm fires, so the package as a whole is simply running too slowly to finish. The cause is the runner, not the tests. These two lanes are the only ones driving the full Go suite against a live PostgreSQL service container, and that container is badly I/O-bound on the managed fleet -- a routine checkpoint logged write=116.7s sync=55.7s over 11169 files, and individual CREATE TABLE statements crossed the store's slow-query threshold at 1.3-1.9s apiece. Same commits on GitHub-hosted runners: test-postgres 5m11s, test-pgvector 1m48s. Raising -timeout would have kept main green while leaving both lanes running 20+ minutes on every push and trusted PR, so pin them back instead and leave the rest of #508's routing untouched. setup-go regains Actions caching here because #513's cache: false exists only to reuse a self-hosted machine-local GOMODCACHE, which no longer applies once the job is hosted. This is a workaround, not a fix -- the fleet's service-container disk I/O still needs attention before these lanes can move back. Generated with Claude Code (claude-opus-5) Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
`test-postgres` and `test-pgvector` have failed on every managed-runner main build since #508. Host telemetry confirms the lanes are storage-bound: PostgreSQL checkpoint syncs take minutes while CPU remains mostly idle. Move both lanes back to GitHub-hosted runners, restore Actions caching, and restore the test commands from their last known-green hosted configuration. This keeps main reliable without hiding the managed fleet's service-container I/O problem behind longer timeouts. The workflow passes actionlint and all repository hooks. The fleet storage bottleneck remains a separate infrastructure follow-up. Co-authored-by: Matthew Jacobs <mjacobs@users.noreply.github.com>
## Summary - route canonical same-repository Linux pull requests and main-branch builds to managed Linux runners, with forks and noncanonical copies falling back to GitHub-hosted runners - invoke reusable workflows from `main` and let checkout use the caller event's immutable SHA without accepting a dispatcher-supplied ref - lint proposed workflow revisions on GitHub-hosted infrastructure The managed runner group admits only the listed reusable workflow files from `main`; PR-controlled dispatcher changes therefore cannot target it directly. Merge kenn-io#511 first so `main` accepts reusable-workflow calls before this PR replaces the existing pull-request trigger. Co-authored-by: Wes McKinney <wesm@users.noreply.github.com>
`test-postgres` and `test-pgvector` have failed on every managed-runner main build since kenn-io#508. Host telemetry confirms the lanes are storage-bound: PostgreSQL checkpoint syncs take minutes while CPU remains mostly idle. Move both lanes back to GitHub-hosted runners, restore Actions caching, and restore the test commands from their last known-green hosted configuration. This keeps main reliable without hiding the managed fleet's service-container I/O problem behind longer timeouts. The workflow passes actionlint and all repository hooks. The fleet storage bottleneck remains a separate infrastructure follow-up. Co-authored-by: Matthew Jacobs <mjacobs@users.noreply.github.com>
1 participant
Summary
mainand let checkout use the caller event's immutable SHA without accepting a dispatcher-supplied refThe managed runner group admits only the listed reusable workflow files from
main; PR-controlled dispatcher changes therefore cannot target it directly.Merge #511 first so
mainaccepts reusable-workflow calls before this PR replaces the existing pull-request trigger.