Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue 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)

Đã đóng
  • Có gì không ổn?
#1,385 2 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

@mikolalysenko đang làm issue này rồi.

Từ ngày 11/10/2026.

  • #1386 của @mikolalysenko — đang mở

Đánh giá

Độ khó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
30/100
Loại issue
Tái cấu trúc
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Đình trệ
Công nghệ
github-actions, rust
Lĩnh vực
ci-cd, devops

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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

Ngôn ngữ chính
Rust
Star
8
Fork
1
Merge trung bình
19 giờ 1 phút
Pull request đã merge (30 ngày)
473

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của SocketDev/socket-patch

Tất cả issue của SocketDev/socket-patch

Issue tương tự

Thêm issue về Rust

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.