source: Usage, Options & Common CI Errors
source executes a file in the current shell, so its variables and functions stick around.
source (or its POSIX form, the dot .) loads env files and helper functions into the running shell instead of a subshell. The portability trap: source is a bashism; POSIX sh only has the dot.
What it does
source reads and executes commands from a file in the current shell context, so any variables, functions, or directory changes it makes persist after it returns - unlike running the script, which uses a subshell that discards them.
Common usage
source ./.env # load vars into this shell
. ./.env # POSIX-portable equivalent
source ~/.nvm/nvm.sh # load nvm into the shell
source venv/bin/activate # Python virtualenv
. "$(dirname "$0")/lib.sh" # load helper functionsOptions
| Form | What it does |
|---|---|
| source FILE | Bash/zsh: run FILE in current shell |
| . FILE | POSIX-portable equivalent of source |
| source FILE arg | Pass positional args to the file |
Common errors in CI
"source: not found" or "source: command not found" - the step ran under /bin/sh (dash on Debian), which lacks source; use the dot: . ./file. Sourcing a script that calls exit terminates YOUR shell (and the step), not just the script. A sourced .env with spaces around = or unquoted values can break parsing or leak globs - prefer set -a; . ./.env; set +a to auto-export cleanly.