CI workflow templates

These templates run a pinned LabWired Core v0.22.2 release and preserve the result.json, uart.log, snapshot.json, and junit.xml artifacts.

GitHub Actions

github-actions.yml is the primary GitHub template. It uses the public Core action at w1ne/labwired-core/.github/actions/labwired-test@75a3d9e906bab90fc0281d1dd786fe479a910d48 as an immutable action-source pin, while version: v0.22.2 independently pins the Core CLI. Its only inputs are script (required), version, output-dir, and whitespace-separated args. The action downloads the public release archive with curl, writes JUnit at output-dir/junit.xml, renders the GitHub report, and always uploads the output directory.

Copy it into a firmware repository, then replace your-firmware and the test script path:

cp docs/integration-templates/github-actions.yml .github/workflows/firmware-test.yml

GitLab CI

gitlab-ci.yml is active as written. Its test job uses:

image:
  name: ghcr.io/w1ne/labwired:v0.22.2
  entrypoint: [""]

The empty entrypoint lets GitLab run its job shell, where the template calls labwired test. Copy it to the repository root and replace your-firmware plus the test script path.

Direct Docker use

For local or non-GitHub CI runs, the release image keeps labwired as its entrypoint:

docker run --rm --user "$(id -u):$(id -g)" -v "$PWD:/workspace" -w /workspace \
  ghcr.io/w1ne/labwired:v0.22.2 \
  test --script tests/firmware-test.yaml --output-dir out/labwired --no-uart-stdout

The Docker command and GitHub action invoke the same test YAML. It may describe one machine directly or a world through inputs.env.

Advanced source builds

Use a source build only to validate an unreleased LabWired revision. Normal CI should use the pinned action or runner image so release behavior is reproducible.

cargo build --release -p labwired-cli
./target/release/labwired test --script tests/firmware-test.yaml --output-dir out/labwired