Path-filter compat matrices on push to main

[Mikola Lysenko (mikolalysenko)]

No open ci-perf issue was eligible this run: every remaining one (#1170, #1267, #1225, #1176, #1171, #1172, #1173, #1174) changes ci.yml or Dockerfile.sbt, which open PRs #1261, #1251, #1247 and #1238 already touch. #1248 is a settings change. This is the largest measurable waste outside those files. Follows up #1198 / #1206.

Problem

Six compatibility workflows run their whole matrix on every push to main, whatever the commit touched: composer, go, npm, pipenv, pnpm and sbt. PDM, Poetry, Bun, vlt and Gradle already filter their push trigger.

Last 24h: 44 push runs per workflow. One successful push run of each (head 2044d9e, plus sbt at 37910916802):

workflow	Linux	Windows	macOS	job-min
sbt	30 jobs / 150.6	2 / 18.9	2 / 13.8	183.3
composer	11 / 33.1	4 / 13.2	3 / 10.3	56.6
npm	11 / 25.6	–	–	25.6
pnpm	4 / 11.9	–	–	11.9
go	4 / 10.5	–	2 / 8.5	19.0
pipenv	2 / 7.9	–	1 / 4.4	12.3
per push	239.6	32.1	37.0

So these six cost ~10.5k Linux + 1.4k Windows + 1.6k macOS job-min/day on push to main alone.

Change

Each of the six gets:

• a push: paths: filter: the ecosystem's pre-CI perf: compatibility workflows (sbt, PDM, vlt, Bun, Composer, +5) — full matrices on ~80% of PR pushes, 0 failures (~80,000 Linux + 26,000 Windows job-min/day) #1198 relevance set (the shared engine code its cells run through, as its PR filter listed before Run compatibility matrices on PRs only for their own files #1206 narrowed it), its current PR paths, and the toolchain files (Cargo.lock, Cargo.toml, crates/*/Cargo.toml, rust-toolchain.toml, .cargo/**). Composer also gets tests/docker/Dockerfile.base and sbt .github/actions/upload-artifact/**, which they use but didn't list.
• a nightly schedule (17 4 * * *, same as vlt and Gradle) that runs the full matrix.

No job changes. The macOS/Windows legs are gated on github.event_name != 'pull_request', so they also run on the schedule. Scheduled runs use refs/heads/main, so they share push's concurrency group (no cancel) and save-if cache saving.

Expected saving

I replayed the last 24h of first-parent main commits (74) against each new filter:

workflow	push runs kept	skipped
composer	50/74	32%
go	35/74	53%
npm	53/74	28%
pipenv	38/74	49%
pnpm	53/74	28%
sbt	58/74	22%

Net of the added nightly run, that is ~2.5k Linux + ~0.34k Windows + ~0.53k macOS job-min/day (≈4.8k on the dashboard's L×1/W×2/M×3 weighting). These workflows don't gate merging, so the merge-queue critical path doesn't change. The gain is runner time and less queue pressure right after merges.

Measured result

• This PR changes only the push/schedule triggers. Its own CI run can't show the saving: the PR edits each workflow file, so all six matrices run on it as before.
• The effect shows after merge as fewer push-event runs of these six workflows. The profiler can verify it: compare total_count of workflows/<w>-compatibility.yml/runs?event=push per 24h against the 44/day baseline above.
• This PR's own CI on 27ea6a0 is all green: CI (25 min) and the six compat workflows (go 4, pipenv 4, npm 5, pnpm 7, composer 10, sbt 21 min) ran on the PR as expected, since it edits their files. Bugbot found no issues.
• Validation: actionlint reports no new findings (the 6 pre-existing anchor/alias findings in go/pipenv are unchanged). zizmor --offline gives 19 findings before and after. YAML parses, and each file's on: has pull_request, push (with paths), schedule and workflow_dispatch.

Where each test still runs

• Every job in the six workflows still runs nightly on main, in full.
• They also run on push to main whenever a commit touches the ecosystem's relevance set or the toolchain.
• On a PR they run when it touches the ecosystem's own files (unchanged since Run compatibility matrices on PRs only for their own files #1206), and on any branch via workflow_dispatch.
• ci.yml's per-ecosystem blocking slice still runs on every PR and in the merge queue. It is untouched.
• ci-ok and clippy are unaffected.

Risk

• A main commit that breaks one of these ecosystems only through code outside its relevance set (for example a shared tests/common helper) is now caught by the nightly run, not that commit's push run. That's up to ~24h later and may cover several commits. This is the same trade vlt and Gradle already make. If per-commit bisectability on main matters more than the ~4.8k weighted job-min/day, close this PR.
• The relevance sets are the lists these workflows' PR filters used until earlier today, so they are the curated set the team already trusted for PR gating.

🤖 Generated with Claude Code

https://claude.ai/code/session_018FBYc7n2aJPmvwCfVGUubD

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

bugbot run

---

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 27ea6a0. Configure here.}

[Mikola Lysenko (mikolalysenko)]

Ready for review at 27ea6a023d2a.

• CI: all checks on this head green (100+ jobs, CodeQL included); merges cleanly into current main (83969ec3).
• Bugbot: reviewed this head, no findings. Already approved by a human on this head.
• Slack: not announced (the Slack connector in this run has no send tool); the next run should retry.
• Diff adds on.push.paths filters to six compat workflows (composer, go, npm, pipenv, pnpm, sbt) plus a nightly schedule run as the backstop; worth a glance that each filter covers the code that workflow exercises.

---

Generated by Claude Code