Skip to main content
Coming soon. The Workflows dashboard UI (visual builder, run graph view, GitHub YAML export) is not yet exposed in the sidebar. The underlying APIs — trigger configuration, workflow runs, and YAML generation — are live today.
A workflow is a directed acyclic graph of steps — each step runs a script on a box, and later steps can depend on earlier ones finishing successfully. Use workflows when a single job isn’t enough: you want a build → flash → test → report pipeline, or you want the same sequence to run on every pull request.

​
Building a workflow

Workflows → New Workflow opens the visual builder:
  1. Drop steps onto the canvas. Each step has a name, a script, a target box (or box group), and optional environment variables.
  2. Draw dependency arrows between steps. Steps with no dependencies run first, in parallel; each later step waits for all of its upstream steps to reach completed.
  3. Configure triggers on the right-hand panel (see below).
  4. Save. The workflow is immediately available to run manually; triggers activate at the next matching event.
Steps communicate by writing artifacts. A build step can emit a firmware binary that a later flash step downloads and applies.

​
Trigger types

TriggerFires when
manualA user clicks Run now, or the workflow is invoked via API.
scheduleA cron expression matches. Cron is evaluated in UTC.
pushA commit is pushed to a configured GitHub branch.
pull_requestA PR is opened, updated, or reopened in the configured repo.
box_onlineA specific box transitions from offline to online.
Multiple triggers per workflow are fine — a workflow can be both scheduled and GitHub-driven.

​
Runs

Each invocation creates a workflow run. The run detail page shows the full graph with per-step status (pending, running, succeeded, failed, skipped). Click a step to see its streamed logs and any artifacts it produced. Runs retain their artifacts and logs per your org’s retention policy. You can re-run a failed run, which creates a fresh run with the same definition.

​
GitHub Actions export

If a workflow has a GitHub repo configured, Stout can commit a generated .github/workflows/*.yml file to that repo. The generated YAML:
  • Translates each Stout step into a GitHub Actions job.
  • Uses the Stout-hosted runner image.
  • Includes the API token needed to dispatch work back through the control plane.
This lets your team see Stout runs inline with their normal GitHub Actions checks, and keeps the workflow definition under version control.
Editing the generated YAML by hand is discouraged — Stout re-generates the file on every workflow edit and will overwrite manual changes. If you need custom steps, add them alongside the generated job in a separate file.

​
Workflow vs. job vs. factory suite

UseWhen
JobOne-off script, no dependencies, ad-hoc debugging.
WorkflowMulti-step automation, reusable, triggered by events.
Factory suiteProduction/QA hardware tests with structured pass/fail steps, camera capture, and reports.