[Mikola Lysenko (mikolalysenko)]

LLM Description written by Claude Code:claude-opus-5-5

Fixes #1681

Problem

coverage and e2e-build had needs: clippy on every run. They needed only clippy's reuse / pr_unchanged outputs, which two API checks set in clippy's first second. So both critical-path chains started ~1.4 min late (run 39880331011: clippy 00:48:50 to 00:50:13, coverage starts 00:50:14). clippy failed in 0 of 256 PR runs in the last 7 days, so the gate cost time on every run and saved nothing.

Change

• The two reuse checks (ci-reuse-merge-group.py, ci-reuse-pr-head.py), their actions: read permission and the reuse / pr_unchanged outputs move from clippy to release-readiness. That job already runs on every event in ~10 s on Depot-4 with no needs, so no job is added. It also gets timeout-minutes: 10.
• coverage and e2e-build now needs: release-readiness only.
• Every other job that reads the outputs needs [release-readiness, clippy], so its gating is unchanged.
• The ubuntu e2e-build consumers (e2e, e2e-extended, e2e-full, cargo-vex-matrix, cargo-vex-matrix-full) now need [e2e-build, clippy], so a red clippy still skips the e2e fan-out. On a normal run clippy (~1.4 min) finishes at about the same time as e2e-build (~0.2 + 1.25 min), so those legs don't start later.
• clippy keeps its name and stays required. ci-ok's needs list is unchanged; it already lists both jobs. The Depot mapping and the DISABLE_DEPOT_RUNNERS switch are unchanged. windows-compile-check, merge-queue fail-fast and push reuse are untouched.

Runner usage (lean PR run)

	before	after
jobs	~28 Linux	same set, none added
job-minutes, green run	baseline	about the same (the ~1 s of reuse API calls moves between jobs)
coverage start	~1.42 min after the run starts	~0.2 min
ci-ok	7.90 min (merge_group 39880331011), 9.57 (PR 39882946034)	6.55 min measured on this PR's own run (39903308723)
red clippy	coverage + e2e fan-out skipped	coverage + e2e-build (~8 job-min on 16 vCPU) still run; fan-out skipped. 0 such runs in 7 days

Measured on this PR

Run 39903308723 (head e312474): release-readiness 04:59:56 → 05:00:05. coverage and e2e-build started at 05:00:06, while clippy was still running until 05:01:26. The Gradle e2e leg started at 05:01:27, right after clippy (e2e-build finished at 05:01:23). ci-ok was green at 05:06:29: 37 checks passed, 50 were skipped by the lean scope, none failed. Bugbot reviewed e312474 with no findings.

Tradeoffs and review findings not changed

• A failed release lint now also skips the gated test jobs (/code-review finding). This is the cost of reusing release-readiness instead of adding a job. ci-ok fails either way. The cases are a version-bump PR whose CHANGELOG section or tag isn't ready yet, or a transient git fetch error in the lint. In those cases the author gets the lint error first, and a re-run of failed jobs re-runs the skipped ones. A dedicated preflight job would avoid this at the cost of one extra runner per run. I didn't add one because PR and merge-queue usage must not grow.
• ci-reuse-pr-head.py still takes the previous run's clippy success as evidence that the run wasn't draft-skipped (finding). Reuse also requires the previous ci-ok to be green, and a failed release-readiness fails ci-ok, so a run whose gated tier never ran can't count as evidence. Not changed.

Tests

• scripts/tests/test_ci_scheduling.py now pins the new graph. Only coverage, e2e-build and windows-compile-check may skip clippy, and the e2e consumers' exact needs are asserted. A new test checks that every job reading needs.<job>.outputs lists <job> in its needs, because otherwise the output is silently empty and every reuse gate turns off.
• Red to green: on origin/main's ci.yml the updated test file fails 21 subtests; with this change python3 -B -m unittest discover -s scripts/tests runs 369 tests, all OK (6 skipped). Removing clippy from e2e-extended's needs makes the test fail, as intended.
• actionlint 1.7.7: the same 37 pre-existing findings as main (YAML anchors), no new ones. zizmor --offline: 59 findings, the same as main. A PyYAML parse confirms every needs.X.outputs reference has X in its needs.
• No Rust code changed.

#1639 also touches ci.yml, but it is a no-op against main (its uv pin landed in aea79f5) and changes different lines.

https://claude.ai/code/session_01U44M4RmSQr6xHiiJxjzrvx

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

BugBot review

---

Generated by Claude Code

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit e312474. Configure here.}

[Mikola Lysenko (mikolalysenko)]

Labeled Ready for review (burn-down agent).

• Head: e312474
• CI: 87/87 settled (37 success, 50 skipped), no failures
• Bugbot: reviewed e312474, no findings; no open review threads
• Reviewer note: CI-only change (.github/workflows/ci.yml + scheduling test). Coverage and e2e-build no longer wait on clippy.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

Final review brief

What it does. Moves the two CI-reuse checks (and their reuse / pr_unchanged outputs and actions: read permission) from clippy into the ~10 s release-readiness job. coverage and e2e-build can then start without waiting on clippy. The e2e and cargo-vex consumers still need clippy, so a red clippy still skips the e2e fan-out.

Risk: low. Only the job graph and output wiring change. Cache keys, concurrency, triggers and runners are untouched, and the ci-ok aggregate is unchanged (if: always(), same needs list, including clippy, release-readiness, coverage and e2e-build). A red clippy or release-readiness still fails both required checks.

Look here

• ci.yml:271: release-readiness now owns the reuse outputs and permission
• ci.yml:582 (coverage) and ci.yml:1011 (e2e-build): the only jobs that no longer wait on clippy
• ci.yml:2792: ci-ok, unchanged
• test_ci_scheduling.py:45 and :581: new scheduling checks, plus a guard that every needs.X.outputs reader lists X in needs

Verified.

• Read the full diff. No needs.clippy.outputs reference is left. release-readiness keeps clippy's draft guard, so the set of jobs on each event (including merge_group) is unchanged.
• python3 -B -m unittest discover -s scripts/tests: 369 OK.
  • The new tests fail 21 subtests against main's ci.yml.
  • They also catch mutations: dropping clippy from the e2e consumers, or adding it back to e2e-build.
• CHANGELOG untouched.
• CI e312474: 37 passed / 50 skipped, 0 failed. Cursor Bugbot: passed, no open threads.

Changes I made. None.

Open questions (non-blocking)

• A release-lint failure in release-readiness now also skips the gated tests. On push to main that includes the cache-writer jobs. The PR accepts this tradeoff, and it is worth knowing.
• The comments rely on merge-queue fail-fast, but no workflow YAML implements it (it would be a queue setting). Without it, a red clippy in the queue still fails, just after coverage and e2e-build finish.

Auto-merge is armed: approving sends it straight to the merge queue.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

[agent] On the final review's second open question: merge-queue fail-fast is in a workflow, not a queue setting. .github/workflows/merge-queue-fail-fast.yml triggers on merge_group and runs scripts/merge-queue-fail-fast.py (tests: scripts/tests/test_merge_queue_fail_fast.py), which cancels the queue run on the first failed job. So a red clippy in the queue still cancels coverage and e2e-build early. This PR doesn't touch either file.

---

Generated by Claude Code