Workflows & CI

Shipping firmware is a CI problem the software industry solved a decade ago, except the tests need to talk to an oscilloscope. Stout brings the same pipeline-as-code model to physical hardware: declare a workflow as a YAML document with ordered or parallel steps, each with its own box requirement, script, timeout, and artifact expectations. Steps can depend on other steps, consume their outputs, and gate on pass/fail conditions.

Triggers cover the cases hardware teams actually need. Manual triggers let you run a workflow on demand from the dashboard. Schedule triggers handle overnight regression suites and nightly calibration runs. Push and pull-request triggers wire to a GitHub App that installs on the repositories containing your firmware, so every commit can spin up the full hardware-in-the-loop suite on a real board before a review begins. Webhook triggers handle the long tail — anything that can POST JSON can start a workflow.

What turns this into a gate rather than a notification is branch protection. Hardware results arrive as a GitHub check run, which means they sit alongside unit tests and linting as a check a repository can require — a firmware change that has never run on a real board cannot be merged, and the policy lives in the repository settings instead of in a reviewer's memory. Secrets follow the same logic: an API key, a signing credential, or a per-unit serial number is stored encrypted in Stout and injected at runtime, so making hardware tests a merge requirement never becomes a reason to commit credentials to the repo in order to satisfy it.

When a workflow run completes, every step gets its own log stream, artifact list, and timing breakdown. You can replay the exact job that ran on the exact box with a single click. Failed runs can be retried from the failing step instead of restarting the entire pipeline, which matters when step three takes forty minutes to warm up a thermal chamber.