Promote a script into a flow

Goal

The script you have been iterating on, running in a flow, without a rewrite.

Why bother

This is the payoff for developing on the CLI at all.

Without this	With this
Prototype in one place, rewrite for automation	The same file, unchanged
Two behaviours to debug — the script, and the port	One
A fix in production has to be back-ported to test it	Run the same file locally

kis script uses the same engine and calling convention as a flow’s script: task. That is a guarantee you can lean on, not a coincidence.

Step 1 — the script, unchanged

function main(region) {
  const rows = data.query("orders", { region: region });
  return { region: region, count: rows.length };
}

Developed with:

kis script run summarise.js west --debug

Step 2 — reference it from a flow

name: regional-summary
vars:
  region: west
tasks:
  - name: summarise
    script:
      language: javascript
      file: ./summarise.js
      args: ["{{region}}"]

The file is the same file. What was a positional argument on the command line is args here.

Step 3 — restate what does not travel

Flags are not part of the script, so anything you set on the command line has to be declared in the task:

CLI flag	In the flow
positional args, --args	args:
--func handler	function: handler
--namespaces log,http	The task’s namespace configuration
--timeout 50	The task’s timeout
--vars name=x	Flow vars:, interpolated into args

--namespaces is the one to get right. A script you developed with all and deploy without restriction is unrestricted in the place it matters — see Restrict what a script can reach.

Step 4 — keep the fast loop

Promoting does not mean giving up the CLI. Reproduce a failing flow task locally with the same arguments:

kis script run summarise.js west --debug --namespaces log,db,json

Match the namespaces the flow grants and you are reproducing the flow’s conditions, not approximating them.

Inline or file

The script: task takes the body one of two ways, and one of them is a dead end for everything else in this section.

Form	Use when
file:	The script is more than a few lines, or you want to run it with kis script
code:	It is short and only meaningful in that flow

Prefer file: for anything you will iterate on. A body inlined with code: cannot be run, validated or benchmarked with the CLI — it is not a file, so there is nothing to point the CLI at.

Verify

Run the flow with --dryrun first, then for real, and compare the task’s result with what the CLI produced for the same arguments. They should be identical — if they are not, the difference is in the flags, not the script.

Related

• Run your first script
• Restrict what a script can reach
• DevSecOps how-tos — the flows this plugs into