ci: pivot — keep coverage hosted, add self-hosted serial standby lane

Direction change after review discussion. Moving a REQUIRED check onto a single in-house VM traded merge-path availability for modest savings and accumulated trust/contention caveats (six review rounds' worth). Revert every coverage-lane change: coverage stays on the enterprise Ubuntu 24.04 32-core pool exactly as on master. Instead, add serial-linux-selfhosted: on every master push the in-house pool (vm-backup) runs the complete unsharded primary aggregate as a hot-standby drill. It blocks nothing, yet continuously proves the environment end to end, so any hosted-pool outage can be answered with a one-line runs-on retarget onto continuously verified capacity. Push-triggered lanes execute the base branch's own workflow definition, so no PR-editable path selects these runners — the entire fork-trust discussion is structurally moot for this lane. Topology notes (en/zh + pairing records) describe the standby lane and the switch play.
2026-07-26 00:08:26 +08:00
parent f09539581d
commit 310a387b14
7 changed files with 57 additions and 45 deletions
@@ -12,13 +12,13 @@ Larger runners make it possible to pay setup once and parallelize inside the rep

 ## Decision

-The enterprise keeps repo-restricted x64 larger-runner pools for Ubuntu and Windows. Ordinary pull requests name two 32-core hosted pools directly: Ubuntu latest for the remaining primary Node 24 inventory and Windows 2025 for blocking Windows contracts. Exhaustive coverage moved off the metered Ubuntu 24.04 32-core pool onto the in-house self-hosted pool (`vm-backup` label: a 64-core VM running four always-on systemd-managed runner instances plus four registered spares) for trusted same-repo PRs; untrusted PRs — forks and Dependabot — keep coverage on the hosted Ubuntu 24.04 32-core pool so dependency-supplied code never reaches the persistent VM. **Precondition: repository forking stays disabled.** The workflow's pool selector is defense-in-depth only — `pull_request` executes the PR's own workflow definition, so YAML cannot enforce runner trust against a fork that edits it. Disabled forking (org-side, not PR-editable) is the enforcement boundary; the planned public release is an isolated read-only mirror under a separate org, preserving this. Before forking is ever enabled, the runners must first move into an org-level runner group restricted to this repository with base-branch workflow pinning — that migration is the gate, not a follow-up. Public IPs are disabled, and workflow concurrency remains bounded because an autoscaling ceiling neither allocates idle machines nor makes repository work scale without limit.
+The enterprise keeps repo-restricted x64 larger-runner pools for Ubuntu and Windows. Ordinary pull requests name three 32-core pools directly: Ubuntu 24.04 for exhaustive coverage, Ubuntu latest for the remaining primary Node 24 inventory, and Windows 2025 for blocking Windows contracts. Public IPs are disabled, and workflow concurrency remains bounded because an autoscaling ceiling neither allocates idle machines nor makes repository work scale without limit.

 The required primary path depends on those enterprise pools. Standard GitHub-hosted jobs retain the Node 22.19, Node 26, and Python SDK compatibility contracts, while the [portable recovery boundary](2026-07-23-portable-required-pull-request-ci.md) and [serial reference](2026-07-21-serial-cross-platform-ci-reference.md) keep complete standard-runner evidence available on `master`. `suite=larger-runner-benchmark` compares isolated critical lanes across provisioned sizes, and `suite=consolidated-runner-benchmark` compares whole aggregates. Each benchmark reports its observed processor and memory capacity before running repository work.

 The former gate-level and coarse primary shard jobs are absent from the workflow. Their static, lint, coverage, snapshot, and scenario shard selectors are also absent from the repository, so an unused diagnostic path cannot preserve a second CI architecture.

-Linux primary work uses three independent jobs: static gates and the consumer tail on hosted 32-core pools, and coverage on the in-house self-hosted 64-core pool for trusted PRs (hosted 32-core for untrusted ones). Coverage runs alone with its own worker bound, and the static scheduler runs alone so its result has no post-build consumer tail. After static gates finish, that job publishes its emitted `apps/*/lib`, `packages/*/*/lib`, and `vendor/*/lib` tree as a run-scoped artifact. The third job restores that exact tree, then starts lint, Node 24 runtime compatibility, build-backed snapshots, and all artifact consumers without repeating the build. Generated NodeNext consumer directories are excluded from ESLint discovery because the artifact check removes them while these processes overlap. The pnpm store and ESLint cache are restored without putting cache uploads on the pull-request critical path. Performance reports use each job's `startedAt` to `completedAt` interval; runner queue delay is capacity evidence, not repository execution time.
+Linux primary work uses three independent 32-core jobs. Coverage runs alone with its own worker bound, and the static scheduler runs alone so its result has no post-build consumer tail. After static gates finish, that job publishes its emitted `apps/*/lib`, `packages/*/*/lib`, and `vendor/*/lib` tree as a run-scoped artifact. The third job restores that exact tree, then starts lint, Node 24 runtime compatibility, build-backed snapshots, and all artifact consumers without repeating the build. Generated NodeNext consumer directories are excluded from ESLint discovery because the artifact check removes them while these processes overlap. The pnpm store and ESLint cache are restored without putting cache uploads on the pull-request critical path. Performance reports use each job's `startedAt` to `completedAt` interval; runner queue delay is capacity evidence, not repository execution time.

 Windows shares one 32-core setup across the blocking build and production site plus observational built-artifact contracts. Linux owns the duplicate lint, coverage, and snapshot inventories because running those observational copies on Windows extends the paid critical path without adding a blocking platform claim.

@@ -48,6 +48,8 @@ The process-bound coverage project contains exactly five suite files. Thirty-two

 Complete serial Linux, macOS, and Windows references run only when `master` moves. Pull requests use the enterprise required path plus standard-hosted compatibility jobs, while other larger-runner sizes run only by manual dispatch.

+An additional serial Linux reference runs on the in-house self-hosted pool (`vm-backup` label: a 64-core VM with four always-on systemd-managed runner instances plus four registered spares) on every `master` push. It is a hot-standby drill, not a required check: each run re-proves that the persistent VM can execute the complete unsharded aggregate, so if the enterprise pools degrade, a required lane can be retargeted with a one-line `runs-on` change onto an environment with continuously verified evidence. Because the lane is push-triggered, it always executes the base branch's workflow definition — no pull-request-editable path can route code to these runners, and the repository additionally keeps forking disabled.
+
 ## Alternatives considered

 **Keep the three coarse primary Linux lanes.** The core, CPU, and production-site jobs met the latency targets, but they paid three setup waves and left primary Node work sharded after larger runners were available. The all-size trace showed that one unnecessary dependency, not a lack of host capacity, kept the single-box aggregate above one minute.