[WIP] ci: add shared dependency gate to skip stale-lock CI runs#5939
Draft
TonyCTHsu wants to merge 2 commits into
Draft
[WIP] ci: add shared dependency gate to skip stale-lock CI runs#5939TonyCTHsu wants to merge 2 commits into
TonyCTHsu wants to merge 2 commits into
Conversation
TonyCTHsu
added
the
AI Generated
dd-octo-sts
Bot
added
the
dev/github
🎉 All green!🧪 All tests passed 🎯 Code Coverage (details) 🔗 Commit SHA: 7207e8b | Docs | Datadog PR Page | Give us feedback! |
A dependency PR triggers CI twice: once on the contributor's commit (gemfiles changed, lockfiles still stale) and again on the lock-dependency bot's regenerated-lock commit. On the first, stale run every bundler-dependent job fails BUNDLE_FROZEN, wasting compute - most expensively the macOS matrix (6 jobs, ~10x runner billing). Add a reusable Dependency Gate workflow (_deps_gate.yml) as a single source of truth, adopted by the workflows that lacked an early gate: test-macos, test-yjit, and check (via its build job). The gate reuses lock-dependency's dorny/paths-filter + dependency_filters.yml to detect dependency changes, then probes every base gemfile for lockfile consistency. Dependent jobs run only when proceed == 'true'. The probe (deps_gate_probe.rb) calls Bundler's frozen equivalence check without installing gems or hitting the network, so it is cheap and runs once under Ruby 4.0 / Bundler 2.7.2 regardless of each job's Ruby. This keeps the first, stale run cheap; it cannot reduce the two runs to one, since the bot's lock commit always re-triggers CI.
TonyCTHsu
force-pushed
the
ci-deps-gate
branch
3 times, most recently
from
a9cb833 to
73d0740
Compare
…eavy workflows Refines the gate scope based on per-workflow cost analysis. Two distinct waste shapes call for two tools: - Jobs that fail-fast or waste setup BEFORE the lock-dependency bot commits (macOS fails in ~12s but bills 6 jobs at 10x; Nix wastes its dev-shell build before the frozen bundle fails) cannot be helped by cancellation — they need the gate, which prevents them from starting on a stale-lock commit. Gate now guards test-macos and nix only. - Jobs that run long enough to be cancelled mid-flight when the bot's lock commit supersedes them (system-tests ~27min, memory-leaks) are better served by cancel-in-progress, which is simpler and also covers ordinary force-pushes. Drops the gate from test-yjit and check: both run on cheap 1x runners and fail in ~12s on a stale lock, so the gate's overhead roughly equals the waste it would save. Adds cancel-in-progress (scoped to non-master refs, matching test.yml so master and scheduled runs are never cancelled) to the heavy workflows that lacked it: test-macos, test-yjit, nix, test-memory-leaks, system-tests, codeql-analysis.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What does this PR do?
Reduces wasted CI on dependency PRs, which trigger CI twice: once on the contributor's commit (gemfiles changed, lockfiles still stale) and again on the
lock-dependencybot's regenerated-lock commit. The first, stale run is pure waste. Two tools, matched to two waste shapes:Dependency gate (
.github/workflows/_deps_gate.yml, reusable): achangesjob (reusingdependency_filters.yml) plus a probe that checks each base gemfile against its lockfile via Bundler's frozen equivalence check — no gem install, no network. Guarded jobs run only whenproceed == 'true'. Applied to Test macOS and Test Nix, whose jobs fail-fast (~12s, but macOS bills 6 jobs at 10×) or waste setup before the bot commit lands — so cancellation can't help; the gate must stop them from starting.cancel-in-progressadded to the heavy workflows that lacked it (test-macos, test-yjit, nix, test-memory-leaks, system-tests, codeql). For long-running jobs (system-tests ~27min) the bot's lock commit supersedes the stale run mid-flight, and cancellation recovers most of the waste — simpler than a gate, and it also covers ordinary force-pushes. Scoped to non-master refs so master and scheduled runs are never cancelled.Motivation:
A stale dependency-PR run wastes the most on expensive/long jobs: macOS (6 jobs × 10× billing) and system-tests (~27 min). YJIT and check were deliberately left out — they run on 1× runners and fail in ~12s, so the gate would cost about as much as it saves.
Change log entry
None.
Additional Notes:
Draft/WIP. Both gate paths are verified live: non-dependency PRs run the guarded jobs normally; a simulated stale-lock dependency PR skipped macOS/Nix as intended (the lock-dependency bot then regenerated the lock and re-triggered CI).
How to test the change?
On this PR's own CI (no dependency change): Test macOS and Test Nix run normally (
proceed == 'true'). A stale-lock dependency PR is what triggers the skip; the bot's relock re-runs everything on the final commit.