Running pipelines

flow run

Loads pipeline.ts, validates it, and executes the stages. Use -f for a file somewhere else:

flow run -f pipelines/release.ts

Parallelism

Stages declare what they need; the scheduler works out what can overlap. -j caps how many run at once:

flow run -j 3

Given this graph — three checks that each need only install:

-j 3 runs lint, typecheck and test together, then build once all three pass.

Above -j 1 the output switches from streaming to grouped: each stage's output is buffered and flushed as one block when it finishes, so concurrent stages never interleave into nonsense.

✓ Typecheck  106ms
  $ npm run typecheck
[07:11:27] typecheck: 0 errors

✓ Test  106ms
  $ npm run test
[07:11:27] test: 12 passed

✓ Build  76ms
  $ npm run build
[07:11:27] build: dist/ written

✔ Run succeeded in 536ms

Ordering comes entirely from needs. With -j 1 stages run in array order; above that, array order stops mattering and only the graph does — a stage missing a needs it actually depends on will surface the moment you raise -j.

Watch mode

flow run -w

Re-runs on every save until you press Ctrl-C. It ignores .flowwright, .git, node_modules, dist, coverage, .next, .turbo and .cache, and debounces for 150 ms so a multi-file save is one run, not six.

watch mode — runs are not recorded to history

Watch runs are deliberately not written to history. A watch session produces a run per keystroke-burst, and recording them would bury the runs you actually care about in flow list.

Skipping history

flow run --no-history

Nothing is written to .flowwright/state.db or runs/. Worth using in CI, where the job is thrown away afterwards and the reporter output is what you keep.

History failures never fail a run: if the database can't be opened, flow prints a dim (run history off: …) and executes anyway.

Container stages

A stage can declare a container image, and by default those stages run in Docker. If Docker isn't available, FlowWright runs the stage on the host instead and says so rather than failing.

Force it explicitly with:

flow run --no-docker

Useful on a CI runner that's already inside a container.

When something fails

Nothing new is scheduled after a stage fails, and the run reports what broke. Under -j, stages already running are allowed to finish — see Dependencies and ordering.

▶ Test
  $ node -e process.exit(2)
✗ test  19ms

✖ Run failed in 87ms

  failed stage: test
  command:      node -e process.exit(2)
  exit code:    2

flow exits with the same code the command did — 2 here, not 1. Stages marked continueOnError record their failure and let the run carry on.

Ctrl-C, or a SIGTERM from a CI runner, cancels the run: it stops, finishes writing any reports, and exits 130. A second Ctrl-C gives up immediately.

JUnit output

flow run --junit report.xml

Writes a JUnit XML report in addition to whatever the console reporter is doing — it never replaces it. See Reporters and Running in CI.

Watching the run programmatically

--reporter json streams the run as newline-delimited events instead of rendering it. Every field of every event is on the Events reference.