Adopting Bash Strict Mode for Reliable CI Scripts

Problem: Silent failures in CI scripts

When a Bash script runs in a CI pipeline, a missing file or a typo in a variable name often does not stop the job. The script may continue, producing misleading logs or deploying a broken artifact. This happens because Bash, by default, ignores non‑zero exit codes from simple commands and treats an unset variable as an empty string.

What Bash strict mode does

Enabling set -e makes the shell exit immediately when any simple command fails, set -u turns references to undefined variables into errors, and set -o pipefail causes a pipeline to return the exit status of the first failing command instead of the last one. Together they are called “strict mode” and give you fail‑fast behavior.

Enabling strict mode and IFS hygiene

Place the following lines near the top of every script, before any logic that depends on the environment:

#!/usr/bin/env bash
set -euo pipefail
IFS=$'\n\t'   # limit word splitting to newline and tab

The IFS assignment prevents Bash from splitting filenames on spaces, which reduces surprises when a build artifact is named my lib.so. You need execute permission on the file (chmod +x script.sh) and you can run it locally or let your CI runner invoke it.

Worked example: catching a typo and a broken pipeline

Consider this minimal script saved as demo.sh:

#!/usr/bin/env bash
set -euo pipefail
IFS=$'\n\t'

# Intentional typo: BUILD_DIR misspelled as BUID_DIR
echo "Using directory ${BUID_DIR}"

# A pipeline where the first command fails
false | true
echo "This line should never run"

To try it, save the file, make it executable, and run it from a terminal:

chmod +x demo.sh
./demo.sh

Because set -u is active, the reference to the unset variable BUID_DIR triggers an error message similar to:

demo.sh: line 7: BUID_DIR: unbound variable

The script exits before the pipeline is evaluated, so you never see the output from false | true. If you comment out the typo line and run the script again, set -e combined with set -o pipefail causes the pipeline false | true to fail, and the script stops before the final echo. You can verify the behavior by checking the exit code with echo $? after each run; it will be non‑zero when strict mode catches a problem.

Trade‑offs and limitations

• set -e does not trigger inside the test part of an if or while statement, nor inside && or || lists. A construct like if grep pattern file; then … will continue even if grep fails, which is often desirable but can be surprising.
• set -u aborts on any intentional use of an optional variable. To safely use a default you must write ${VAR:-default} or test with ${VAR+set}.
• set -o pipefail changes the semantics of pipelines that are meant to ignore upstream failures, such as yes | head -n 5. In those cases you can temporarily disable pipefail with set +o pipefail around the specific pipeline.
• Applying strict mode to a large, legacy script may expose hidden bugs and cause the job to stop mid‑execution. Introduce it gradually, run the script in a staging environment, and fix the reported issues before enabling it on production branches.

Checking that strict mode is active

You can inspect the current options with set -o. The output will show errexit on for -e, nounset on for -u, and pipefail on for -o pipefail. Adding a line like set -o | grep -E 'errexit|nounset|pipefail' near the top of a script and logging the result can help you confirm that the mode survived any sourcing or sub‑shells.

Actionable closing

Start every new Bash script with the strict‑mode block shown above, test it in a feature branch, and enable it for existing scripts only after you have cleared the reported errors. This small change turns silent, hard‑to‑debug failures into immediate, actionable messages, making your CI pipelines more predictable and your releases safer.