Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de 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)

Cerrado
  • ¿Algo no está bien?
#1,385 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@mikolalysenko ya está trabajando en esto.

Desde el 11/10/2026.

  • #1386 de @mikolalysenko — abierto

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
30/100
Tipo de issue
Refactorización
Claridad
Bien especificado
Estado de actividad
Estancado
Stack tecnológico
github-actions, rust
Área
ci-cd, devops

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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

Lenguaje dominante
Rust
Estrellas
8
Forks
1
Merge medio
19 h 1 min
PR fusionados (30 d)
473

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de SocketDev/socket-patch

Todos los issues de SocketDev/socket-patch

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.