.shipfox/workflows/. It defines the automation: what jobs to run, which steps to execute, and what triggers start a run. Because workflows live in your repo, they are versioned, diff-able, and reviewable like any other code.
Workflow structure
Every workflow file begins with a small set of top-level fields. Here is a complete example showing all supported keys:Human-readable name shown in the dashboard. Must be at least one character.
Default runner label or list of labels for all jobs in this workflow. Each job can override this value with its own
runner: field. If omitted, jobs must specify their own runner.Environment variables available to
run steps across all jobs. Keys must follow POSIX-style variable naming ([A-Za-z_][A-Za-z0-9_]*). Values can be strings, numbers, or booleans — the runtime stringifies numbers and booleans before execution. Not applied to agent steps.Named triggers that start a workflow run. Each entry is a named key with a
source and event. A workflow with no triggers block can only be started manually via the API or dashboard. See Triggers for the full schema.Named jobs that make up the workflow. At least one job is required. Job names are used as identifiers in
needs references and in the dashboard run view.Where workflow files live
Shipfox scans.shipfox/workflows/ in your connected repository for workflow definitions. Each .yml file in that directory is treated as one workflow definition — one file, one workflow.
A few rules to keep in mind:
- Any
.ymlor.yamlfile under.shipfox/workflows/is picked up. Files are matched by path prefix and extension, so nested paths such as.shipfox/workflows/ci/build.ymlare scanned too. - The filename is not the workflow name. The human-readable name comes from the top-level
name:field inside the file. You can name the file anything you like. - Both
.ymland.yamlextensions are accepted. Pick one and stay consistent for readability.
Env variables
Theenv block at the workflow level sets environment variables that are inherited by every run step in every job. Job-level and step-level env blocks follow the same format.
There are a few important constraints:
- Values may interpolate.
envvalues support${{ }}expressions, resolved when the run is created fromrun,trigger,event, andinputscontext — for example${{ trigger.source }}. See Expressions. envapplies only torunsteps. Declaringenvdirectly on an agent step (prompt) is rejected by the schema validator. Workflow-level and job-levelenvis also not forwarded to agent steps.- There is no unset syntax. Setting
FOO: ""setsFOOto an empty string. An emptyenv: {}block does not remove variables inherited from the runner’s process environment. - Do not put secrets in
env. Values are stored in the committed workflow file and in the saved step config — they are not masked in logs.
Step env > Job env > Workflow envThe nearest scope wins. A step-level declaration always beats a job or workflow declaration of the same name.
Roadmap
filter evaluation, loop, matrix, and branch are roadmap features. ${{ }} template interpolation is supported today — see Expressions.Related pages
Jobs & Steps
How jobs and steps are structured and executed inside a workflow run.
Triggers
The full trigger schema and which sources are supported today.
Runners
Where jobs execute and how to register your own runner.