Skip to content

CI perf: e2e-build-windows — full Windows test build is the merge-queue critical path in 27/30 runs (~2.5 min off every merge) #1385

Description

Measurement

Window: 2026-10-10 12:17 → 2026-10-11 12:17 UTC. All 30 CI merge_group runs in the window, with job detail for 29 of them.

event p50 p90
clippy done 1.30 1.38
e2e-build-windows starts (it needs: clippy; queue wait 0.03 min) 1.33 1.43
coverage done (the slowest Linux job) 7.10 7.97
e2e-build-windows done 9.45 9.68
ci-ok done 9.58 9.95
  • Enqueue → merge for 14 PRs merged in the window: p50 10.3 min, so this one job sets about 25% of every merge's queue time.
  • Example: run 38085373608, job 114310908115.

Where the time goes

Step times in e2e-build-windows, p50 / p90 (n=29):

  • Checkout 0.15 / 0.25
  • Install Rust 0.18 / 0.22
  • Cache cargo 0.32 / 0.52. The cache hits on a full key (~226 MB), but cache-workspace-crates: false, so only third-party dependencies are restored.
  • Compile the CLI and every CLI test target 7.18 / 7.33. This step runs cargo test --locked -p socket-patch-cli --all-features --tests --no-run. The log shows socket-patch-core and socket-patch-cli rebuilt from scratch, then every CLI integration-test binary codegen'd and linked: Finished test profile in 7m 14s.
  • Bundle + compress + upload: about 0.2 min. The step uploads a 41 MB e2e-bin-windows-latest artifact, but in lean scope no job downloads it. Its consumers (e2e-windows, cargo-vex-matrix-windows) are gated on vars.CI_SCOPE == 'full', schedule or dispatch.

For comparison, the Linux e2e-build runs the same compile on depot-ubuntu-24.04-16 in 0.78 min.

Root cause

#1378 added this job to the merge queue to catch cfg(unix) slips (#1324), because lean PR runs skip Windows. It reuses the full *e2e-build-steps, so it pays for codegen and linking of about 60 test binaries on a 4-vCPU hosted runner, plus a bundle no one reads. It also waits for clippy, but only to read outputs.reuse, and that output can only be true on push to main. This job doesn't run on push in lean scope.

Proposed fix

In .github/workflows/ci.yml, give the lean merge-queue Windows check its own job, windows-compile-check, instead of e2e-build-windows:

  1. Drop needs: clippy so it starts at t≈0. Keep e2e-build-windows, with its needs, for full scope, schedule and dispatch, where its artifact is consumed. Split the if: so exactly one of the two runs per event.
  2. Type-check instead of build: cargo check --locked -p socket-patch-cli --all-features --tests. This keeps the guarantee Warn on yarn classic member-dir vendored installs (#691) #1324 needs (every cfg(windows)/cfg(unix) path in the CLI and its tests type-checks on Windows) without codegen or linking about 60 test binaries.
  3. Skip the bundle, compress and upload steps in the check job.
  4. Add the new job to ci-ok's needs, and keep ci-ok and clippy as the required check names.
  5. Optional: add cache-workspace-crates, or let the nightly run save the cache. save-if is main only, and lean pushes to main never run this job, so the Windows cache is refreshed only by nightly and dispatch runs.

Alternative if a full link is wanted: run the job on a Depot Windows runner with more cores behind the same DISABLE_DEPOT_RUNNERS switch. That needs a Depot plan check, so it is more effort.

Expected saving

  • Merge-queue critical path: the check ends at an estimated ~4–5 min (1.3 min earlier start, and the compile estimated at ~3–3.5 min as a check, against 7.2 as a build), which is before coverage (7.1). merge_group created → ci-ok would go from p50 9.6 / p90 9.95 to about 7.1 / 8.0 min: ~2.5 min off every merge, ~24% of enqueue → merge.
  • Windows: about 30 × 4 ≈ 120 Windows job-min/day at today's weekend volume (more on weekdays).
  • PR feedback latency: no change, since this job doesn't run on PRs.

Coverage and risk

  • Windows type-checking of every CLI test target still gates the queue. Linking and running on Windows stays in full scope and nightly (e2e-windows, test (windows-latest), cargo-vex-matrix-windows), as today.
  • A Windows-only link error (rare; the crates are pure Rust) would surface in the nightly run instead of the queue.
  • The required check names ci-ok and clippy are unchanged.

Effort

S: one new job, an if: split and a ci-ok needs entry in ci.yml.

ROI

Saving ≈ 2.5 critical-path min + 0.12k Windows min × 2 ≈ 2.7; confidence 0.8; effort S=1 → ROI ≈ 2.2.


Generated by Claude Code

Activity

  1. mikolalysenko commented on Oct 11, 2026

    @mikolalysenko
    CollaboratorAuthor

    [agent] Triaged (CI lane, p3) and verified on origin/main 578b63e: e2e-build-windows runs on merge_group (ci.yml:1021), needs: clippy, and reuses *e2e-build-steps (full --no-run build + bundle upload) with no lean-scope consumer. Claiming this issue (shared root cause: lean merge-queue Windows check does a full test build instead of a type-check). Branch: agent/fix-ci-windows-compile-check. Claim-ID: 2026-10-11T12:50:51Z-f7942b


    Generated by Claude Code

  2. mikolalysenko commented on Oct 11, 2026

    @mikolalysenko
    CollaboratorAuthor

    [agent] Draft PR: #1386


    Generated by Claude Code

  3. added a commit that references this issue on Oct 11, 2026
    6842cce
  4. mikolalysenko commented on Oct 11, 2026

    @mikolalysenko
    CollaboratorAuthor

    [agent] First merge-queue run with #1386: run 38162899863.

    • windows-compile-check started 3 s after the run did and finished at minute 4.3 (4.2 min job, cold cache: the nightly hasn't saved check-windows-latest yet). Before, e2e-build-windows took about 8.2 min and started after clippy.
    • From run created to ci-ok: 8.0 min, against a p50 of 9.6 before. The critical path is now coverage, which finished at minute 7.9; Windows is no longer on it.
    • Lean queue run: 30 jobs, about 35.4 job-min (about 38.2 before).

    Once the nightly has saved the check cache, the Windows job should get shorter, but it no longer gates the queue either way.


    Generated by Claude Code

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions