ci-fix

name	ci-fix
description	Scan all CI builds and tests, find failures, fetch error logs, and fix the code. Prioritizes unit tests, example tests, then uno, attiny85, esp32s3, esp32c6, teensy41. Use when CI is red and you need to diagnose and repair build/test failures.

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:

1. unit tests — unit_test_linux, unit_test_macos, unit_test_windows — fix first, these validate core logic
2. example tests — example_test_linux, example_test_macos, example_test_windows — validate example compilation
3. uno — AVR 8-bit, most constrained, most users
4. attiny85 — AVR tiny, extreme flash/RAM constraints
5. esp32s3 — ESP32-S3, primary ESP target
6. esp32c6 — ESP32-C6, RISC-V ESP target
7. teensy41 — Teensy 4.1, ARM Cortex-M7
8. 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:

1. Read the error logs from the scan output
2. Run the failing test(s) locally: bash test or bash test <TestName>
3. If a test fails, re-run in debug mode: bash test <TestName> --debug
4. Identify the root cause and fix the source code or test
5. Verify: bash test

For example test failures:

1. Read the error logs from the scan output
2. Run the failing example(s) locally: bash compile wasm --examples <ExampleName>
3. Identify the root cause (missing include, type error, API change, etc.)
4. Fix the source or example code
5. Verify: bash compile wasm --examples <ExampleName>

For board build failures:

1. Read the error logs from the scan output
2. Identify the root cause (missing header, type error, platform ifdef, linker error, etc.)
3. Find the relevant source file(s) and read them
4. 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
5. 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