Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

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)

Offen
  • Stimmt etwas nicht?
#1,385 2 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

@mikolalysenko arbeitet bereits daran.

Seit 11.10.2026.

  • #1386 von @mikolalysenko — offen

Bewertung

Schwierigkeit
3/5
Geschätzter Aufwand
1-2 Tage
Anfängerfreundlichkeit
30/100
Issue-Typ
Refactoring
Klarheit
Klar beschrieben
Aktivitätsstatus
Veraltet
Tech-Stack
github-actions, rust
Bereich
ci-cd, devops

Rechercherichtung

Start in .github/workflows/ci.yml; compare the existing e2e-build-windows job and ci-ok dependencies. Check the linked pull request #1386 to see the work already underway. Done means the merge queue uses the proposed Windows type-check job while full-scope Windows builds retain their artifact path and required check names.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

agent:claimed agent:triaged ci-perf priority:p3

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.

  • The merge queue's critical path is now one hosted Windows job. Since #1375 (lean gate), #1362 (Depot Linux) and #1378 (Windows compile in the queue) merged, a merge_group run is created → ci-ok in p50 9.6 / p90 9.95 min (n=30). e2e-build-windows (windows-latest) was the last job before ci-ok in 27 of 30 runs.
  • If that job is left out, the last job finishes at p50 7.1 / p90 7.97 min. That job is coverage in most runs and the Gradle e2e leg in the rest.
  • Timeline, p50 minutes after the run is created (n=29):
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 #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

Vorherrschende Sprache
Rust
Sterne
8
Forks
0
Ø Merge
19 Std. 44 Min.
Gemergte PRs (30 T.)
450

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus SocketDev/socket-patch

Alle Issues in SocketDev/socket-patch

Ähnliche Issues

Weitere Issues zu Rust

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.