Files
Ruben Fiszel 248540ac4d feat: bounded-cascade selective execution for pipelines (UI + CLI) (#9695)
* feat: bounded-cascade selective execution for pipelines (UI + CLI)

Run a prefix of a pipeline cascade: from a schedule/manual root, fan
downstream but stop at chosen end node(s) — the path-between set over the
asset-graph lineage DAG. Exposed as a canvas 'Run downstream up to…' pick
mode and a 'wmill pipeline run <folder> --to' CLI command. No backend or
parser changes; reads the existing graph, tags, and triggers.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* feat: surface bounded-run on the run caret, trigger-node kebab, and Test button

Move 'Run downstream up to…' from the runnable kebab onto the play-button
caret popover (Edit mode, next to Run / Run + trigger N downstream); add it
to the trigger-node kebab so schedule/data_upload entrypoints expose it on
the View page; and to the ScriptEditor Test split caret for the open script.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix: address CI review on bounded-cascade (cubic)

- Port CLI engine test from Deno to bun:test under cli/test/ (won't run under bun test otherwise).
- closure() now excludes the start node on a cycle back to it (descendants/ancestors contract); regression tests both engines.
- CLI 'pipeline run --to' rejects unresolved/ambiguous end tokens instead of silently running a different subset.
- Sort a copy in the runSelection order test so the launch-order assertions aren't invalidated.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix: address standing review nits on bounded-cascade

Resolves the four recurring P1/P2 findings from the codex/pi/claude
reviews:

- UI gate (P1): the canvas/trigger-node "Run downstream up to…"
  affordance was gated on the subscriber-only downstream map, so a valid
  start whose only downstream is a pure reader had a non-empty bounded
  set but no menu entry. Gate on the read-aware lineage downstream
  (buildLineageDownstreamMap), matching the bounded engine.
- waitJob (CLI): a completed job without explicit success:true now
  counts as a failure, mirroring the frontend waitJobTerminal — the
  cascade only advances on a confirmed success.
- Comment fix (CLI): the unbounded `run` path uses the read-aware
  lineage DAG (pure readers included); dropped the false "parity with
  the canvas cascade" (subscriber-only) claim.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix: expose bounded-run caret for pure-reader-only starts (codex P1)

The canvas wiring from the prior commit passed `onStartBoundedRun` from
the read-aware lineage map, but the leaf components still hid the popover
that holds the "Run downstream up to…" action behind a subscriber-only
gate:

- RunnableNode rendered the Run-button caret only when
  `hasCascade = downstreamCount > 0` (subscriber-only). A valid start
  whose only downstream is a pure reader got `onStartBoundedRun` but no
  visible action. Now the caret opens when there's a cascade OR a
  bounded-run start (`hasCaret`), and the "Run + trigger N downstream"
  item is gated on `hasCascade` so it never reads "trigger 0".
- ScriptEditor's Test split button activated only when
  `downstreamSubscribers > 0`, falling through to a plain Test button
  (no caret) otherwise. Now it also activates when `onBoundedRun` is
  set, with the "Test + trigger N" item gated on the count.

For a manual root (no trigger-node kebab fallback) with a pure-reader
downstream this was the only UI entry point, so it was previously
unreachable. Verified in-browser: a manual-root script writing an asset
read-only downstream now exposes "Run downstream up to…" on the
ScriptEditor Test caret with the cascade item hidden.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix: gate ScriptEditor bounded-run on read-aware downstream; fix CLI asset-end warning (codex P2)

- Details-pane (ScriptEditor) bounded-run entry was gated only on
  `validStartPaths`, broader than the canvas which also requires
  read-aware downstream (`hasLineageDownstream`). An isolated start could
  thus expose "Run downstream up to…" and enter pick mode with no
  selectable end. Now gated on `lineageDownstreamPaths` (script paths with
  a downstream in `buildLineageDownstreamMap`), matching the canvas.
- CLI dropped-end warning called `scriptPathOf(d)` unconditionally, which
  slices `script:`-length chars off an asset id too — `datatable:main/raw`
  printed as `le:main/raw`. Now prefix-checks like the JSON output.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix: correct --from error to exclude only row-backed event triggers (codex P2)

The bounded-start validation message listed `kafka/webhook/…` as event
triggers that can't start a bounded run, but webhook/data_upload are
rowless and read as manual roots (valid starts). Only the row-backed
native kinds (kafka/mqtt/nats/postgres/sqs/gcp/email — EVENT_TRIGGER_KINDS)
are excluded; the message now names those.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix: surface dropped ends in CLI JSON; disambiguate shared-trigger bounded start (codex P2)

- CLI `run --json` silenced the dropped-end warning, and the JSON payload
  echoed the originally-resolved `--to` list with no reachable/dropped
  split — a resolved-but-unreachable end looked like a clean plan that
  silently runs only the start. JSON now includes `reachableEnds` and
  `droppedEnds` (shared `idLabel` helper, asset-id safe).
- Trigger nodes dedupe per (kind, ref), so a schedule shared across
  scripts collapses to one node, but `recordSourceTrigger` kept only the
  first target path — the bounded-run action then rooted at an arbitrary
  script (or hid when only that first script lacked downstream). Now all
  target paths are tracked and the action is offered only when exactly one
  is a valid start with downstream; multi-eligible nodes suppress it
  rather than guess.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix: don't run hidden drafts in View-mode bounded cascade (codex P1)

launchCascadeScript unconditionally preferred drafts.get(path) over the
deployed script. In View mode with drafts hidden (displayGraph is
deployed-only), a bounded run started from a trigger-node kebab would
execute preview jobs from hidden local draft content instead of the
deployed scripts the user is looking at.

Gate draft execution on `mode === 'edit' || includeDrafts` — the exact
condition under which displayGraph includes drafts — so execution always
matches the displayed graph. No-op for scripts without a draft; the
edit-mode "Run + trigger N downstream" cascade is unchanged.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-25 12:08:05 +02:00
..
2022-11-01 15:53:28 +01:00
2023-02-03 19:49:46 +01:00
2026-02-23 09:09:16 +00:00
2025-12-26 20:32:42 +00:00

Windmill CLI

A simple CLI allowing interactions with windmill from the command line.

You can find more information in Windmill Docs

Installation

Install the wmill CLI tool using npm install -g windmill-cli.

Update to the latest version using wmill upgrade.

Workspaces

To get started run wmill workspace add or use the instructions from the workspace settings.

Running Flows & Scripts

Run a script or flow using wmill flow/script run u/username/path/to/script and pass any inputs using --data + Inputs specified as a JSON string or a file using @ <filename> or stdin using @-.

Curl-style syntax using -d @- for stdin or -d @<filename> is also supported.

Flow Steps and Logs will be streamed during execution automatically.

CLI input example

Pushing Resources, Scripts & More

The CLI can push specifications to a windmill instance. See the examples/ folder for formats.

Switch to a different workspace

wmill workspace switch <workspace_name>

Sync a workspace

Pull

wmill sync pull

Push

wmill sync push

We recommend using the --yaml option to use yaml instead of json as the encoding format. Yaml will be made the default soon.

Pushing individual files

You can push individual resources using wmill <type> push <file_name> \<remote_name\>. This does not require a special folder layout or file name, as this is given at runtime.

Listing

All commands support listing by just not providing a subcommand, ie wmill script will result in a list of scripts. Some allow additional options, learn about this by specifying --help.

User Management

You can add & remove users via wmill user add/remove, and list them using wmill user

Pulling

You can pull the entire workspace using wmill pull

Completion

The CLI comes with completions out of the box via wmill completions <shell>. (Via cliffy)

Bash

To enable bash completions add the following line to your ~/.bashrc:

source <(wmill completions bash)

Fish

To enable fish completions add the following line to your ~/.config/fish/config.fish:

source (wmill completions fish | psub)

Zsh

To enable zsh completions add the following line to your ~/.zshrc:

source <(wmill completions zsh)

Development

AI Guidance Variants

wmill init can now materialize alternate AI guidance bundles without changing the generated defaults in the repo, but this is exposed as internal env-var overrides rather than public CLI flags.

Examples:

WMILL_INIT_AI_SKILLS_SOURCE=/path/to/custom/skills wmill init --use-default
WMILL_INIT_AI_SKILLS_SOURCE=/path/to/custom/skills WMILL_INIT_AI_AGENTS_SOURCE=/path/to/AGENTS.md wmill init --use-default
WMILL_INIT_AI_SKILLS_SOURCE=/path/to/custom/skills WMILL_INIT_AI_CLAUDE_SOURCE=/path/to/CLAUDE.md wmill init --use-default

This is the same guidance-writing path used by the benchmark CLI under ai_evals/, so the benchmark harness and wmill init now generate the same project guidance shape:

  • AGENTS.md
  • CLAUDE.md
  • .agents/skills/*
  • .claude/skills/*

Testing with a local windmill-yaml-validator

To test local changes to the validator before publishing, use npm link:

# In windmill-yaml-validator/
npm run build
npm link

# In cli/
npm link windmill-yaml-validator

Running Tests

Prerequisites:

  • PostgreSQL running locally (default: postgres://postgres:changeme@localhost:5432)
  • Rust toolchain installed

Run tests locally (full features):

bun test test/

Run tests in CI mode (minimal features, skips EE tests):

CI_MINIMAL_FEATURES=true bun test test/
Variable Description
CI_MINIMAL_FEATURES Set to true to skip EE-dependent tests
DATABASE_URL PostgreSQL connection string
EE_LICENSE_KEY Enterprise license key for EE features