Motir

Found while diagnosing MOTIR-4137 — production had been stale for 13 hours and the scheduled workflow that says so had been red four times, with nothing in any of the four run summaries.

Reproduction

gh run view 33615840787 --job 100201332884 --log — the step's own script is echoed, then:

##[error]Process completed with exit code 1

0.2 s later. echo "$report" never ran, and neither did the $GITHUB_STEP_SUMMARY block below it.

Cause

The step body opens set -uo pipefail — deliberately without -e. But GitHub's default shell for a run: block is bash --noprofile --norc -e -o pipefail {0}, and set -uo pipefail does not clear the -e the shell already started with. So:

report=$(node scripts/assert-deploy-freshness.mjs "${args[@]}" 2>&1)
code=$?                      # never reached
echo "$report"               # never reached

An assignment from a failing command substitution takes the assignment's exit status, -e fires, and the step dies before a single line of the report is emitted. The code=$? two lines down is dead code that only reads as defensive.

Why it matters

The comment above the summary block states the intent exactly: "whoever opens a red scheduled run wants 'behind by what, since when' on the first screen, without expanding a step." The step delivers that only when the script exits 0 — i.e. only when the deploy is FRESH and there is nothing to report. On every run where the report has something to say, it says nothing, and the reader gets a bare exit code.

Acceptance criteria

1. A red Deploy freshness run shows the script's report in the step log and in the run summary — asserted on a real failing invocation, not only a passing one.
2. The step's exit status still reflects the script's, so the check stays red.
3. The -e that caused it is neutralised explicitly (set +e, or shell: bash with the flags the step actually wants) rather than worked around by making the script exit 0.