jhheider / mdtask / 30134709098

85%

push

github

feat: shell tasks stop at the first failure (#12)

A shell task runs its whole fenced block as one script, so without `set -e` a
failing early command is swallowed and the task exits with the status of the
LAST command. That quietly turns a multi-step gate into one that cannot fail: a
`check` task reported success while `cargo fmt --check` was failing inside it,
and CI caught what the gate was supposed to. just avoids this by running each
line separately and stopping at the first error; mdtask hands the block to a
shell, so now it asks the shell for the same behavior.

Strict by default, `Opts: no-strict` to opt out, because the failure modes are
asymmetric. A strict default fails loudly when an author did not expect it and
they add the flag. A lenient default fails silently and is trusted anyway. The
other evidence is that authors were already writing the prelude themselves:
every multi-step task in the dogfood repos opens with `set -euo pipefail`. When
everyone writes the same first line, it belongs in the tool.

Scope is deliberately narrow. Only `set -e` and `pipefail`, which are about
detecting failure, the runner's actual job. NOT `set -u`: catching an unset
variable is a lint, and it changes the meaning of correct scripts, since reading
an optional variable is ordinary in a task file. `pipefail` is skipped for plain
`sh` because it is not POSIX and dash rejects it outright, which would break
every task on a Debian-ish /bin/sh. Non-shell interpreters get nothing injected,
since shell syntax in a Python script is a syntax error.


Claude-Session: https://claude.ai/code/session_016wrSiZfmH1jnLESCR41Xzw

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

82 of 83 new or added lines in 1 file covered. (98.8%)

1025 of 1255 relevant lines covered (81.67%)

6238.42 hits per line