Docs: give the local onboard sweep the same marker shape as CI - #1637
Conversation
Everywhere a doc told the reader to run the full a2a3 scene-test sweep on real hardware, it gave a bare `pytest examples tests/st --platform a2a3` — the exact invocation `.claude/skills/testing/SKILL.md` warns "is *not* what CI runs and will report failures that CI never sees": it mixes the SDMA cases with the `sweep's` `aicore_op_timeout` fault-injection test, which is the collision the dedicated SDMA step exists to prevent (hw-native-sys#1425, and the ~306 s fault teardown an SDMA-provisioned device pays). All nine sites now carry `-m "not sdma"` and name the marker, so a local sweep reproduces CI instead of surprising it: - `README.md`, `docs/user/reference/cli.md`, `examples/README.md` — hardware scan lines - `docs/testing.md` — both hardware scan sites; the first gains the separate `-m sdma` pass after it, with the reason - `docs/troubleshooting/a2a3-507899-aicpu-shared-so-fault.md` — the repro scan - `src/{a2a3,a5}/runtime/{tensormap_and_ringbuffer,host_build_graph}/docs/ SUBMIT_BY_CLUSTER.md` — the three final-validation scans Sim lines and single-directory invocations are untouched — the marker only matters where SDMA and fault injection can meet. `st-onboard-a5` carries no marker filter, so a5 scan lines stay as they were. The two `ci.yml` comments claiming the SDMA step runs "on its own dedicated device(s)" get the same correction applied to the docs in hw-native-sys#1617: device disjointness holds only on aarch64, where the step takes `task-submit --device auto`; the x86_64 branch shares `${DEVICE_RANGE}` with the sweep and ordering is the separation. Left deferred since hw-native-sys#1617 because touching `ci.yml` books the whole matrix — this change does that anyway. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (9)
📝 WalkthroughWalkthroughThe change documents SDMA test isolation in CI and updates hardware test commands to exclude SDMA cases by default. Separate commands now run SDMA cases with the ChangesSDMA test isolation
Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
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 |
Summary
Everywhere a doc told the reader to run the full a2a3 scene-test sweep on real hardware, it gave a bare
pytest examples tests/st --platform a2a3— the exact invocationtesting/SKILL.mdwarns "is not what CI runs and will report failures that CI never sees": it mixes SDMA cases with the sweep'saicore_op_timeoutfault-injection test, the collision the dedicated SDMA step exists to prevent (#1425, ~306 s fault teardown on an SDMA-provisioned device).Nine sites now carry
-m "not sdma"and name the marker:README.mddocs/testing.md-m sdmapass with the reasondocs/user/reference/cli.mdexamples/README.mddocs/troubleshooting/a2a3-507899-aicpu-shared-so-fault.mdSUBMIT_BY_CLUSTER.md×3 (a2a3/a5 × tmr, a2a3 hbg)Untouched, deliberately: sim lines (no SDMA cases), single-directory invocations (marker irrelevant), and all a5 scans (
st-onboard-a5has no marker filter).Also fixed, the deferred
ci.ymlcomments — the two that claimed the SDMA step runs "on its own dedicated device(s)", flagged in #1617 and left until ci.yml was next touched for a substantive reason. Device disjointness holds only on aarch64 (task-submit --device auto); the x86_64 branch shares${DEVICE_RANGE}and ordering is the separation. This change touchesci.yml, so the full matrix runs — which was the reason it had been deferred.Testing
pytest examples tests/st --platform a2a3/pytest examples --platform a2a3site: none remain unfiltered (except the SKILL.md warning sentence, which is not a command)st-onboard-a5)ci.ymlin the diff → full matrix expected