Skip to Content
kusaw docsv1.0.0

Pipeline

A [pipeline](../glossary.md#pipeline) is the order of steps a run walks through.

A pipeline is the order of steps a run walks through.

What it is

A pipeline is the order of steps a run walks through. You write that order in the factory. The factory then follows it for every task you add. The pipeline is unattended: once the run has started, steps run without you until they finish, fail, or hit a gate.

Order is the simple case: spec-check, then a loop of build and review and verify, then deliver. Around that, three shapes matter.

A loop repeats a group of steps until the checks in that group pass, or until it runs out of tries. The demo's build-review loop is this: implement, review, verify, and if verify fails, try again. A parallel group runs several steps together — two reviews at once, for example — and then joins. Finally steps run after the pipeline, including after a failure, so a retro or a score can still look at the run. The pipeline is made of stages: loops, parallel groups, gates, and finally.

The pipeline is not a description of your product. It is the path every run of this factory takes. Intake is a separate, interactive path you use when you are still writing the task. Adding a file with kusaw add skips intake and starts at the pipeline.

What you see

In kusaw.yaml you see pipeline: as a list. A name in the list is a step. A loop block names a group, a try limit, and the steps inside. A parallel block names steps that run together. A gate is a stop for you. finally: is a second list that always gets a chance after the pipeline, except when you stop the run outright.

On the run page you see the same shape as a path: the current step, a loop labelled as try n of m, a parallel group as several steps in flight, a gate as waiting for you. When a loop passes, you see which try passed. When it gives up, you see that it ran out of tries or that a try changed no code.

You do not see a separate pipeline for each task. One factory, one pipeline. Recipes are opt-in overlays that change parts of that path; they do not replace it unless you merge them in.

What you decide

You decide the order. Put cheap checks early. Put deliver last among the unattended steps if you want a commit only after the checks pass. You decide which group of steps should loop, and how many tries that group gets. You decide which steps may run together, and whether the group should stop at the first failure or let every member finish.

You decide what belongs in finally — work you want even when the pipeline failed. You decide where a person must look, by putting a gate in the list. You do not have to put a gate in; the demo has none by default.

You decide whether a recipe's overlay is worth merging. The factory does not switch a default because a variant won a benchmark. See Recipes.

Where to go next

Meet the pipeline as the pipeline and finally lists in kusaw.yaml, and as the path drawn on a run in the Dashboard.

  • Step — one job on that path
  • Run — one task walking the path
  • Gates — a stop on the path
  • Recipes — optional changes to the path
  • kusaw.yaml — the file that holds the order
  • Example pipelines — four custom shapes you can copy

On this page