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

CI perf: floating toolchain versions in ci.yml e2e — upstream uv 0.13.2 red-mained the merge queue for 2.7 h (~4.3k job-min wasted on 10-20; ~0.45k min/day amortized)

Ouverte
  • Quelque chose ne va pas ?
#1,645 3 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 20/10/2026.

  • #1647 par @mikolalysenko — ouverte

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
35/100
Type d'issue
Fonctionnalité
Clarté
Clairement spécifiée
Activité
Active
Stack technique
github-actions, go, node.js, python, rust
Domaine
ci-cd, devops, tooling

Piste de recherche

Read .github/workflows/ci.yml at the listed e2e tool setup steps and .github/workflows/pin-check.yml to see how workflow pins are checked. The issue proposes exact Python, Node, and Go versions plus lint for floating versions, allowing matrix values only when exact; it also describes an optional change to merge-queue-fail-fast.py. Done means the required pins and checks are in place and their workflow validation passes.

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-19 20:16 → 2026-10-20 20:16 UTC. I fetched jobs (filter=all) for all 129 merge_group CI runs, 4 push runs, the nightly, and 10 of 30 PR runs.

  • Upstream uv 0.13.2 (PyPI, 10-19 20:59) broke e2e (ubuntu-latest, e2e_vex_build, pipenv:: --ignored, 2026.8.0): uv pip install -r pylock.toml → "The target environment is not supported by the lockfile". In the 18:13 head run that leg ran on base 14eee88 with no PR code involved (job 118803601782).
  • The cause was the astral-sh/setup-uv step in the Pipenv / pip legs. It had no version:, so it always installed the latest uv.
  • First red: nightly 39376690526 at 05:46. First fix PR: #1639 at 15:47, about 10 h later.
  • What actually fixed main: the same pin also rode inside an unrelated PR, #1605, as version: "0.13.1" (commit aea79f5). It merged at 18:38. #1639 is still open and now duplicates that pin.
  • Merge queue stalled 15:54 → 18:38 (2 h 44 min, 0 merges). 17 consecutive queue heads built on red base 14eee88 failed that same leg and were evicted, about one every 6–7 min:
  • Wasted compute: 111 of 129 merge_group CI runs were cancelled or failed. They burned 4,320 of 5,154 merge_group job-min (84%), Linux plus Windows. This does not count the fail-fast and janitor watcher runs (128 more ubuntu-latest runs).
  • Latency: the 10 PRs merged in the window were first enqueued at 15:50–15:51 and merged at 18:38–19:02, so first enqueue → merge took 167–191 min (p50 ~172). Their fast-host norm is 8–12.

This is the second upstream-drift incident in a week: the 10-14 nightly broke on old-uv legs and needed #1525.

Where the time goes

  • Each eviction cycle took about 6–7 min: the pipenv leg fails about 5–6 min in, then fail-fast cancels the run and the queue rebuilds 5 entries.
  • 17 cycles × about 5 runs × about 40 job-min each came to roughly 4.3k job-min.
  • None of that work could succeed: every entry's base already failed the leg.

Root cause

The e2e legs take some oracle tools at floating versions:

  • setup-uv with no version: (now pinned on main).
  • python-version: '3.12.x' (ci.yml lines 1428 and 2682).
  • node-version: '24.x' (lines 1422, 2241 and 2637).
  • go-version: '1.24' (lines 403, 620 and 2702).

pin-check.yml enforces SHA pins for uses: only. Nothing enforces exact tool versions, so any upstream release can turn main red and stall the merge queue until a human lands a pin.

Proposed fix

  1. Close #1639 or rebase it to a no-op. Main already carries version: "0.13.1".

  2. Pin the remaining floating toolchains in ci.yml to exact patch versions:

    • python-version: '3.12.x' → '3.12.<n>'
    • node-version: '24.x' → '24.<m>.<p>' (the matrix legs already use 24.21.0)
    • go-version: '1.24' → '1.24.<p>'
    • Add a comment on each pin: "bump deliberately".

  3. Extend pin-check.yml (or add scripts/check-tool-pins.py) to fail when:

    • an astral-sh/setup-uv / setup-uv step has no with.version;
    • any *-version: value under with: ends in .x, is a bare major or major.minor (e.g. '1.24'), or is latest.

    Matrix expressions (${{ matrix.* }}) are allowed when the matrix values are themselves exact.

  4. Optional: in merge-queue-fail-fast.py, when the failing entry's ref is pr-<n>-<base_sha> and the same job also failed on the latest schedule or push run for base_sha, post a step summary saying "base is red, not this PR's failure". That points a human at the real fix sooner. It is observability only and changes no gating.

Expected saving

  • The cost of one incident like 10-20: about 4.3k Linux+Windows job-min, plus about 2.7 h of zero merges (10 PRs delayed about 160 min each).
  • Amortized at about 1 incident per 1–2 weeks (10-14 old uv, 10-20 uv 0.13.2): about 0.3–0.6k job-min/day and about 10–20 merge-queue min/day on average. The spikes are far worse.
  • Critical path / PR latency on normal days: 0.

Coverage and risk

  • Every test still runs in the same place. Only the tool versions change, from floating to pinned.
  • New upstream releases then reach CI through deliberate bump PRs, which run the full PR gate, instead of through main.
  • ci-ok and clippy names are unchanged.
  • Risk: pins go stale. The bump PRs are cheap, and the pins keep CI reproducible.

Effort

S. One workflow edit plus about 40 lines of lint.

ROI

(0.45k job-min/day + ~15 MQ-min/day) × 0.6 confidence ÷ 1 (S) ≈ 9.3. The incident-weighted queue minutes dominate.

Generated by Claude Code

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

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.