Build history

Every execution of a job, with per-step detail. Filter by status and by runner.

Retention is shared: the Retention (days) setting in Settings → Build sweeps build records, artifacts and audit entries together.

Steps

A build is a list of steps, planned when the build starts:

• In flow mode, one step per action.
• In script mode, a single step.

Each step keeps its own status, output, exit code and duration. When a step fails, later steps are marked Skipped — unless the action has continue on failure set.

Every step is its own shell

Steps share the working directory. They do not share environment variables. To pass a value on, append to the file Walis points at:

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 avoids a step silently depending on the shell state of the one before it.

Parallel groups

Mark a step run alongside the previous step; consecutive marked steps form one group that runs together.

Within a group:

• The working directory is shared.
• Each step gets its own $WALIS_ENV_FILE — a shared one would let them overwrite each other. The files are merged back into the main variable table once the group finishes.
• The aggregated log does not update live (concurrent writers would interleave into nonsense); per-step output still streams normally.
• If a step without continueOnError fails, the rest of the group still finishes before the build stops.

Reading the output

The log window lists steps on the left and the selected step's output on the right, with the trigger, runner, exit code and duration in the header.

While a build runs, output updates every two seconds and the pane follows the tail. Scroll up and it stops following — so you can read something without fighting the scroll.

Artifacts produced by the build are listed underneath and can be downloaded. AI analysis sends the failing output to your configured provider and summarises what went wrong.

Matrix builds

A job with a matrix produces one build per combination, each labelled with its values, which are also injected as environment variables. The cap is 50 combinations — four axes of five values is 625 builds, which is rarely what anyone meant.

Build cache

Paths listed in the job are saved after a successful build and restored before the next one. The order matters and is deliberate: Walis cleans the workspace first, then restores the cache. Reversed, cleaning would delete what was just restored.

Absolute paths and .. are ignored.