perf(ci): run shared-code changes against a core board set, not all 80 - #1397
Merged
Conversation
Closes #1396. `ci/ci_common_paths.txt` force-ran every per-board workflow, by design — its guidance said "be BROAD here". With `crates/fbuild-core/**`, `crates/fbuild-cli/**`, the workspace manifest and lockfile all on that list, a one-line edit almost anywhere scheduled all 80 board builds, ~94 checks per PR. Under `strict: true` branch protection that compounds: every merge makes every other open PR out-of-date, each needs a fresh full sweep, and the queue serializes behind board builds for changes that cannot affect them. ## What changed The render pipeline from #835 already had the right shape; it was missing a core set. `ci/board_families.json` entries can now carry `"core": true`, and `render_paths_for_board` applies the common paths only to those. 17 core boards, covering all 13 families. Two where a family spans genuinely different toolchains rather than different board JSON: esp32 esp32dev (Xtensa) + esp32c3 (RISC-V) stm32 stm32f103c8 (F1/M3) + stm32h747xi (H7/M7) sam due (SAM3X/M3) + samd51p (M4) teensy teensy30 (M4) + teensy41 (M7) Every other board still triggers on its own test dir, its family's crate paths, and its own workflow file — so family-specific work keeps full family coverage. The nightly sweep still runs all 80, moved from 09:00 to 11:00 UTC (3am PST) as the safety net. Measured, by replaying path filters against realistic diffs: fbuild-core one-liner 80 -> 17 fbuild-cli change 80 -> 17 workspace lockfile bump 80 -> 17 ESP32 orchestrator change 9 -> 9 Teensy linker change 8 -> 8 docs only 0 -> 0 ## Also `hw-ci.yml` was the one `pull_request`-triggered workflow with no `concurrency` block, so pushing to a PR branch queued a second hardware run behind the first instead of superseding it. That is worse there than elsewhere: the job holds a physical board, so a superseded run occupies hardware nobody is waiting on. Non-PR events key on `run_id` so scheduled sweeps never cancel each other, matching the rendered per-board blocks. Both source-of-truth comments are updated: being broad in `ci_common_paths` is still correct, it now costs 17 workflows rather than 80. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (82)
📝 WalkthroughWalkthroughThe change narrows board workflow triggers to board-specific paths, marks three boards as core for shared-path changes, updates workflow rendering, adds pull-request run cancellation, and moves the nightly platform schedule to 11:00 UTC. ChangesWorkflow trigger scoping
Estimated code review effort: 3 (Moderate) | ~20 minutes ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Follow-up on #1396. The first pass picked 17 core boards — one per family, two where a family spans distinct toolchains. That is more coverage than shared code needs. Shared-code changes now run three boards: uno AVR (avr-gcc) esp32dev ESP32 (Xtensa) teensy41 Teensy (ARM) One per toolchain family a shared-code change can plausibly break. All three already run on ubuntu-latest and already share one soldr build cache — the `cache-key-suffix: fbuild-rust-debug` in template_build.yml is board-independent by design, so the Rust rebuild happens once and the other two hit it rather than rebuilding. Measured against realistic diffs: fbuild-core one-liner 80 -> 3 fbuild-cli change 80 -> 3 workspace lockfile bump 80 -> 3 ESP32 orchestrator 9 -> 9 teensy linker 8 -> 8 AVR mcu change 11 -> 11 Family-specific coverage is untouched: an ESP32 change still runs all nine ESP32 boards. Everything else is covered by the nightly sweep at 3am. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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.
Problem
ci/ci_common_paths.txtforce-runs every per-board workflow. Its own guidance says so deliberately:That trade has stopped paying. The list includes
crates/fbuild-core/**,crates/fbuild-cli/**,crates/fbuild-paths/**, the workspace manifest and lockfile, and more — so a one-line edit almost anywhere schedules all 80 board builds, ~94 checks per PR.Combined with
strict: truebranch protection this compounds: every merge makes every other open PR out-of-date, each then needs a fresh ~20-minute full sweep, and the queue serializes. Observed directly across a 14-PR session — wall-clock was dominated by re-running board builds for changes that could not affect them.Shape of the fix
The machinery already exists (#835):
ci/render_workflows.pyrenders each board'son: paths:fromci/board_families.json+ci/ci_common_paths.txt, andnightly-platforms.ymlalready sweeps everything daily.What is missing is a core set. Proposal:
Also:
hw-ci.ymlispull_request-triggered but has noconcurrencyblock, so pushing to a PR branch queues another hardware run behind the old one instead of superseding it. It is the only PR-triggered workflow missing that guard — and it matters more there than anywhere else, because those jobs occupy a physical board.Measured effect
fbuild-coreone-linerfbuild-clichangePlatform-specific coverage is unchanged; only the shared-code blast radius shrinks.
Summary by CodeRabbit
CI Improvements
Scheduling
Configuration