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.

Check runs close the loop on pull requests. The GitHub App reports a pending check when a workflow starts, updates it with live progress, and resolves to success or failure with a deep link back to the Stout run page. Reviewers see the same pass/fail status next to unit tests and linting, and repository branch protection rules can require hardware tests to pass before a merge is allowed. If a workflow has secrets — an API key, a signing credential, a serial number — those are stored encrypted in Stout and injected at runtime rather than committed to the repo.

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.