Jobs and steps

A build is a list of steps. Each step is an independent shell with its own status, log, exit code and duration.

Steps are derived from the job when the build starts — the job itself stores no steps, so nothing had to be migrated when this was introduced:

• a job written as a script becomes one step
• a job built from an action flow becomes one step per action

Each step is a fresh shell

The working directory is shared, but environment variables do not carry over. To pass a value on, append to $WALIS_ENV_FILE:

echo "BUILT_VERSION=1.2.3" >> "$WALIS_ENV_FILE"

The next step reads it as $BUILT_VERSION. This matches how other CI systems behave, and it keeps a step from silently depending on the shell state of the one before it.

Failure and parallelism

• A failed step marks the rest Skipped, unless the action is set to continue on error.
• Steps marked run alongside the previous step form one parallel group. They share the working directory but each gets its own environment file, so they cannot overwrite each other.
• The job timeout covers the whole build; each step receives what is left of it.

Matrix builds

Give a job a matrix and one trigger produces one build per combination:

{ "NODE": ["20", "22"], "OS": ["mac", "linux"] }

Each build gets the values as environment variables and carries a label such as NODE=20, OS=mac. Capped at 50 combinations, because four axes of five values is 625 builds and rarely what anyone meant.

Caching

List paths to keep between builds, relative to the working directory. On success they are stored and restored on the next run. The order matters: Walis cleans the workspace first, then restores — the other way round would wipe what it just restored. Absolute paths and .. are ignored.