Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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)

Fermée
  • Quelque chose ne va pas ?
#1,385 2 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

@mikolalysenko y travaille déjà.

Depuis le 11/10/2026.

  • #1386 par @mikolalysenko — ouverte

Évaluation

Difficulté
3/5
Temps estimé
1-2 jours
Accessibilité débutants
30/100
Type d'issue
Refactorisation
Clarté
Clairement spécifiée
Activité
À l'abandon
Stack technique
github-actions, rust
Domaine
ci-cd, devops

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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

Langage dominant
Rust
Étoiles
8
Forks
1
Merge moyen
18 h 19 min
PR mergées (30 j)
504

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de SocketDev/socket-patch

Toutes les issues de SocketDev/socket-patch

Issues similaires

Plus d'issues Rust

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.