tinyusb.git/.github/workflows, branch claude/adoring-pasteur-kbaFa

ci(claude-review): run auto review on Opus (claude-opus-4-8)

2026-06-11T14:13:32Z

The review action currently runs on the default Sonnet 4.6. On PR #3643 (musb EP0 race) it posted "No issues found" while an Opus pass on the same diff surfaced substantive questions (ISR-boundary RXRDY lifetime, regression scope of the DATA-state split). Pin the reviewer to claude-opus-4-8 for higher-signal reviews; subagents keep their cheaper default models. Co-Authored-By: Claude Opus 4.8

Merge pull request #3692 from hathach/claude/bump-claude-review-max-turns

2026-06-11T12:47:01Z

ci(claude-review): raise --max-turns 20 -> 50

2026-06-11T12:41:51Z

The Claude Code Review action runs /code-review:code-review with a hard --max-turns cap. On large PRs (e.g. #3636 "add stm32c5 support", 29 files / +1689), the agent exhausts 20 turns exploring the diff before it can produce and post its review, so the SDK returns an error and the claude-review check fails red with: Reached maximum number of turns (20) Raise the cap to 50 so port-sized PRs complete and post their review. Cost scales with tokens, not the cap: a finished review pays the same whether the ceiling is 25 or 50 — the cap only bites when the agent would otherwise be force-stopped mid-run. Co-Authored-By: Claude Opus 4.8

Merge remote-tracking branch 'origin/master' into stm32c5

2026-06-11T10:20:15Z

# Conflicts: # README.rst

HIL: replace build.flags_on with named build variants (#3687)

2026-06-11T01:16:43Z

* test/hil: replace build.flags_on with named variant schema Boards declare build variants as `variant: [{name, flags}]` instead of `build.flags_on`. The variant `name` is the build dir (cmake-build-) and the HIL report row; `flags` is the raw CFLAGS string (-D...=1) injected via CFLAGS_CLI. No `variant` => a single build named after the board. - build.py: --build-name (dir) + --cflag= (raw CFLAGS, repeatable, =form survives the matrix's shell word-splitting); drop -f1/CFLAGS wrapping. - hil_ci_set_matrix.py: emit one build arg per variant. - hil_test.py: iterate variants; report row + build dir = variant name. - hil_ci.sh: copy all cmake-build-* dirs for -b runs. - get_deps.py: accept (ignore) --build-name/--cflag from matrix args. - tinyusb.json: migrate all 6 flags_on boards to variant. * board_test: park CI build with busy spin instead of wfe

Merge pull request #3690 from hathach/claude/board-test-idle-park

2026-06-10T11:04:54Z

hil: park boards with idle board_test instead of erasing flash

ci: demote sticky-comment report headings to h2; rename HIL report

2026-06-08T09:28:53Z

The Size Difference Report and HIL comments rendered their titles at h1, which is oversized inside a PR comment. Use h2 for both titles (with subsections demoted to h3 to keep the hierarchy), and rename the HIL comment from "HIL test results" to "Hardware-in-the-loop (HIL) Test Report" for consistency. Co-Authored-By: Claude Opus 4.8 (1M context)

ci: include hil-hfp-iar (IAR) results in the HIL PR comment

2026-06-08T09:21:34Z

hil-hfp-iar runs hil_test.py on hfp.json built with IAR on its own rig. Upload its report as the hil-report-hfp-iar artifact and add the job to the hil-report combine job's needs, so the sticky comment shows a third table for the IAR rig alongside tinyusb.json and hfp.json (gcc). The combine gate now runs if either HIL job produced results. Co-Authored-By: Claude Opus 4.8 (1M context)

test/hil: accumulate HIL report across re-runs; post as sticky PR comment

2026-06-08T09:11:13Z

hil_test.py persists results in a hil_report.json sidecar and regenerates hil_report.md from it. A full run starts fresh; a re-run (--skip-board / -bt, i.e. the .skip file) merges into the existing report so already-passed boards/tests are preserved while only re-run cells update. The report dir is configurable via HIL_REPORT_DIR. build.yml: each HIL rig writes the report to a workspace-sibling dir that survives the per-attempt workspace clean, and uploads it as an artifact. A new hil-report job merges the rigs' reports into one sticky PR comment (marocchino) with one table per rig. Co-Authored-By: Claude Opus 4.8 (1M context)

ci: post auto-review findings to the PR (#3684)

2026-06-08T02:42:08Z

Add --comment so the auto-review is actually posted on the PR.