Testing and CI
Different builds exercise different runtime paths. Use a workflow result as evidence only for the commit, target and configuration it actually ran.
Validation paths
Section titled “Validation paths”| Path | What it covers | Boundary |
|---|---|---|
| HELIA Make tests | HELIA adapters with selected kernel dependencies and profiles | A native run uses the host; Cortex-M/MVE execution requires the corresponding target runner. |
| Corstone-300 FVP legs | Target runtime execution for configurations in the HELIA matrix | Simulation does not establish physical-board power or peripheral behavior. |
| Bazel / upstream tests | Upstream test infrastructure and configured reference/other upstream backends | Bazel does not select the HELIA kernel directory. |
| CMake smoke and link probes | Manifest integrity, source integration, cross-compilation and symbol resolution | Successful static compilation/linking does not prove model outputs. |
| Release builds | Architecture/toolchain/flavor artifact creation and release-side probes | Artifact creation is not a benchmark or a complete execution test. |
| Documentation checks | Site content/build/link contracts | Documentation CI is independent of runtime validation. |
Workflow entry points
Section titled “Workflow entry points”tests_entry.yml invokes the HELIA test workflow on pull requests. The ci:run_full label also invokes the broader upstream CI workflow. Draft pull requests skip the jobs in tests_entry.yml (unless labelled ci:run_full) and smoke_cmake.yml; marking the pull request ready for review runs them. Inspect both the trigger and job conditions when requesting additional coverage.
helia_test.yml defines the HELIA GCC and ATfE matrix, including target/profile choices and executed-test floors. smoke_cmake.yml covers manifest and integration checks. Arm Compiler 6 has separate Cortex-M workflow and release workflow paths.
Manual entry points include run_helia.yml and run_ci.yml. The post-merge tests_post.yml has its own job guards; a reusable workflow appearing there does not mean all its jobs execute for every event.
Reproduce a failure
Section titled “Reproduce a failure”Open the failed job and record its commit, container/toolchain revision, exact build arguments and first failing test. Follow its script under tensorflow/lite/micro/tools/ci_build/ rather than substituting a different host build. Preserve the generated log, test counts and any model fixture used by the run.
Report separately whether you configured, compiled, linked, executed on a host, executed in simulation or ran on physical hardware. For kernel changes, verify the test actually dispatches through the changed adapter and does not only exercise a reference fallback.
Public claims
Section titled “Public claims”A measurement needs its model, inputs, runtime/kernel revisions, target, compiler, profile and methodology. Keep single-operator kernel measurements separate from complete-model results. The profiling guide describes what to record when comparing applications.