Skip to main content

​
How the chain runs

The agents you add to a workflow form a chain, and what each one produces and consumes decides how it actually runs:
  1. A step becomes eligible to run once every step it depends on has settled — either finished normally or been legitimately skipped. A step with nothing it depends on is eligible immediately.
  2. Steps with no dependency between them may run at the same time. The order you drag them into sets which earlier steps a later one is allowed to draw on — a step can only consume a kind an earlier step in the list produces — but it doesn’t by itself force one step to wait for another that it doesn’t actually need.
  3. Two steps that both edit the repository never run at the same time, whether or not they depend on each other — they’d be racing on the same checkout. This is mutates-worktree on the agent, not something you configure per workflow.
  4. Each step is told what triggered the run (for a pull-request run: the PR number, head and base commits, the diff) and reads the actual results earlier steps recorded of the kinds it consumes — not a text summary of what an earlier step said it did.
  5. If a step fails, nothing that depends on it runs, and the run ends in error. Workflow steps do not retry by default.
A step whose input turns out to be empty runs zero times and is recorded as skipped — a distinct outcome from failed and from ran and found nothing. See run statuses.

​
Passing results between steps

You don’t wire inputs and outputs together by hand. What flows from one step to the next is exactly what the consuming agent’s consumes names — the actual results (findings, patches, or a kind of your own) that an earlier step’s produces recorded, not a prose account of what happened. What this does not do is let you transform or filter results between steps. If you need different handling, that belongs inside an agent, not between them.

​
Choosing agents

Any agent can be a step — Console’s or your own. Your organization’s agents appear in the picker alongside the built-in ones, and Console treats them identically. A few agents in the library are designed to be spawned by other agents rather than used as steps directly — noted here.

​
Ordering

The rules of thumb:
  • Broad before narrow. Discover first, then act on what was discovered.
  • Declare what a step actually needs. Two steps that don’t consume each other’s output can run concurrently; a step only waits on the steps its consumes names.
  • Expensive before dependent. If a step fails, nothing depending on it runs — so put the step most likely to fail where it costs least.
  • One step is a valid chain. A single scanner plus an output is a complete, useful workflow. Don’t add steps for symmetry.

​
Common chains

​
Editing a chain

In the workflow editor the chain is drawn left to right as pills with arrows:
  • Add with the + button, which searches the agent library.
  • Reorder by dragging a pill.
  • Remove via the grip icon on a pill.
Between 1 and 20 steps.

​
Next steps

The agent library

What’s available to chain.

Configure outputs

Deliver what the chain produces.