ci: run the secret-free post-merge Linux jobs in GKE runner pods - #562

Summary

Run the Linux proof jobs of the post-merge workflows (ci-post.yml, corpus-parity.yml, native-live.yml) on the gke-runners runner group (ephemeral pods, one job per VM, on demand, scale to zero) instead of the GCP VM fleet and the hosted arm64 runner. This is a routing change: no shard count, matrix, job name or check name changes.

The group allows 8 jobs per size label; one run never asks for more (the preflight checker expands matrices and reusable calls and refuses a ninth). A second run close behind queues instead of failing, so a queue in the first rounds is capacity, not a defect.

The jobs run directly in the runner pod. The pod image is the engine toolchain image (compiler, cmake, ninja, python, git-lfs, actionlint, the sanitizer runtime and the other tools the jobs used to install by hand), the runner user has sudo, and the existing dependency steps keep their package lists and their sudo. No job declares a container: or services: block, so nothing is pulled from a public registry at run time.

Not moved: authz, changes and the aggregate jobs (hosted); ci.yml and corpus-parity-subset.yml (pull-request reachable); docs.yml; docs-post.yml, release.yml, promote-baseline.yml, release-ruleset-probe.yml (they hold credentials); every macOS leg.

scripts/ci_preflight.py pins each moved job to its exact runs-on mapping and refuses: the gke-runners group or a gke- label in any pull-request reachable workflow; a secret, id-token, environment or inherited secrets on a job of the group or on a workflow call into it; a job container: or services: block on a moved job; any apt-get line other than the two pinned ones; a paid larger-runner label; more than 8 jobs on one label.

Files (name-status)

M .github/actionlint.yaml
M .github/workflows/ci-post.yml
M .github/workflows/corpus-parity.yml
M .github/workflows/native-live.yml
M docs/ci.md
M scripts/ci_preflight.py
M scripts/test_ci_preflight.py
M scripts/test_ci_release_gate.py

How this is proven

This change is workflow and checker only (no sweep). The lab preflight (lab remote, all 59 stages) passed on the head of this branch. The first ci-post run on main after the merge is the proof of the pod itself; a red leg is fixed forward the same night.

Acceptance read-backs of that first round (each is a plausible whole-leg red that the diff cannot show):

1. Report-sink writer: src/report_sink_writer.cpp opens with O_DIRECT and refuses tmpfs/ramfs. The pod's workspace and /tmp sit on the 80 GiB per-job disk volume, not on tmpfs; the first round confirms the tmpfs-path tests (test_run_json_misc2_tmpfs.py, test_jailed_scratch_tmpfs_tmpdir.cpp) behave as on the VM fleet. If the pod /tmp refuses O_DIRECT, point scratch at the workspace in these jobs.
2. Test counts: compare each moved job's CTest row count and skip count with the last post-fleet run; a lower count, or a new skip in a no-skip row (scripts/run_pytest_no_skips.py), is a regression, not a pass.
3. LeakSanitizer in the pod (sanitizers x4, native-live live-sanitizers): if a fatal LeakSanitizer or ptrace error appears on exactly those jobs, report it; the fix is scoped to those jobs.
4. Python and pip: every moved job that runs pip or pytest sets up Python 3.12 with actions/setup-python first (the pod image carries system Python without pip); the first round confirms "Set up Python" resolves 3.12 and python3 -m pip --version works on the amd64 pods and on the arm64 pod (build-arm). If the arm64 manifest has no 24.04 build, the fix is python3-pip in the image or an ensurepip step for that job.
5. Which workflow ref the runner group checks for a called workflow (caller or callee): the first round shows it. The group lists these workflows at refs/heads/main; a dispatch from another ref queues without a runner.

Rollback: restore the previous runs-on arrays and pins from this commit's parent.

🤖 Generated with Claude Code