Find and fix CI build and test failures across all platforms.
Arguments: $ARGUMENTS
Step 1: Scan builds and get error logs
Run the CI build scanner to discover all failing builds and tests with error context:
uv run ci/tools/gh/ci_builds.py --errors $ARGUMENTS
This auto-discovers workflows from .github/workflows/ matching build_*.yml, unit_test_*.yml, and example_test_*.yml. Adding a new workflow file automatically adds it to this report.
Step 2: Analyze and prioritize
Review the output. Builds are already sorted by priority:
- unit tests — unit_test_linux, unit_test_macos, unit_test_windows — fix first, these validate core logic
- example tests — example_test_linux, example_test_macos, example_test_windows — validate example compilation
- uno — AVR 8-bit, most constrained, most users
- attiny85 — AVR tiny, extreme flash/RAM constraints
- esp32s3 — ESP32-S3, primary ESP target
- esp32c6 — ESP32-C6, RISC-V ESP target
- teensy41 — Teensy 4.1, ARM Cortex-M7
- Everything else — alphabetical within non-priority builds
Fix priority builds first. If --board <name> was passed, focus only on those.
Step 3: For each failing test or build
For unit test failures:
- Read the error logs from the scan output
- Run the failing test(s) locally:
bash test or bash test <TestName>
- If a test fails, re-run in debug mode:
bash test <TestName> --debug
- Identify the root cause and fix the source code or test
- Verify:
bash test
For example test failures:
- Read the error logs from the scan output
- Run the failing example(s) locally:
bash compile wasm --examples <ExampleName>
- Identify the root cause (missing include, type error, API change, etc.)
- Fix the source or example code
- Verify:
bash compile wasm --examples <ExampleName>
For board build failures:
- Read the error logs from the scan output
- Identify the root cause (missing header, type error, platform ifdef, linker error, etc.)
- Find the relevant source file(s) and read them
- Make the fix — prefer the simplest change that fixes the error:
- Missing platform guard → add
#ifdef / #if defined()
- Missing include → add the include
- Type mismatch → fix the type
- API difference → use conditional compilation
- After fixing, verify by compiling:
bash compile <board> --examples Blink
(use the board arg from the scan output, e.g. bash compile uno --examples Blink)
Step 4: Verify fixes don't break other platforms
After fixing a failing build, consider whether the change could break other platforms. If you changed shared code (not platform-guarded), spot-check by compiling another platform:
bash compile wasm --examples Blink
Notes
- The scanner discovers workflows dynamically — no hardcoded list to maintain
- Workflow patterns:
build_*.yml, unit_test_*.yml, example_test_*.yml
- Use
--board uno,esp32s3 to focus on specific boards
- Use
--all flag if you want to see passing builds too (default: only failing with --errors)
- Error logs show up to 5 error blocks per build with surrounding context
- The priority list is defined in
ci/tools/gh/ci_builds.py in the PRIORITY_BOARDS constant
1---2name: ci-fix3description: Find and fix CI build and test failures across all platforms.4---56Find and fix CI build and test failures across all platforms.78Arguments: $ARGUMENTS910## Step 1: Scan builds and get error logs1112Run the CI build scanner to discover all failing builds and tests with error context:1314```bash15uv run ci/tools/gh/ci_builds.py --errors $ARGUMENTS16```1718This auto-discovers workflows from `.github/workflows/` matching `build_*.yml`, `unit_test_*.yml`, and `example_test_*.yml`. Adding a new workflow file automatically adds it to this report.1920## Step 2: Analyze and prioritize2122Review the output. Builds are already sorted by priority:23241. **unit tests** — unit_test_linux, unit_test_macos, unit_test_windows — fix first, these validate core logic252. **example tests** — example_test_linux, example_test_macos, example_test_windows — validate example compilation263. **uno** — AVR 8-bit, most constrained, most users274. **attiny85** — AVR tiny, extreme flash/RAM constraints285. **esp32s3** — ESP32-S3, primary ESP target296. **esp32c6** — ESP32-C6, RISC-V ESP target307. **teensy41** — Teensy 4.1, ARM Cortex-M7318. **Everything else** — alphabetical within non-priority builds3233Fix priority builds first. If `--board <name>` was passed, focus only on those.3435## Step 3: For each failing test or build3637### For unit test failures:381. Read the error logs from the scan output392. Run the failing test(s) locally: `bash test` or `bash test <TestName>`403. If a test fails, re-run in debug mode: `bash test <TestName> --debug`414. Identify the root cause and fix the source code or test425. Verify: `bash test`4344### For example test failures:451. Read the error logs from the scan output462. Run the failing example(s) locally: `bash compile wasm --examples <ExampleName>`473. Identify the root cause (missing include, type error, API change, etc.)484. Fix the source or example code495. Verify: `bash compile wasm --examples <ExampleName>`5051### For board build failures:521. Read the error logs from the scan output532. Identify the root cause (missing header, type error, platform ifdef, linker error, etc.)543. Find the relevant source file(s) and read them554. Make the fix — prefer the simplest change that fixes the error:56 - Missing platform guard → add `#ifdef` / `#if defined()`57 - Missing include → add the include58 - Type mismatch → fix the type59 - API difference → use conditional compilation605. After fixing, verify by compiling: `bash compile <board> --examples Blink`61 (use the board arg from the scan output, e.g. `bash compile uno --examples Blink`)6263## Step 4: Verify fixes don't break other platforms6465After fixing a failing build, consider whether the change could break other platforms. If you changed shared code (not platform-guarded), spot-check by compiling another platform:6667```bash68bash compile wasm --examples Blink69```7071## Notes7273- The scanner discovers workflows dynamically — no hardcoded list to maintain74- Workflow patterns: `build_*.yml`, `unit_test_*.yml`, `example_test_*.yml`75- Use `--board uno,esp32s3` to focus on specific boards76- Use `--all` flag if you want to see passing builds too (default: only failing with --errors)77- Error logs show up to 5 error blocks per build with surrounding context78- The priority list is defined in `ci/tools/gh/ci_builds.py` in the `PRIORITY_BOARDS` constant