export: Usage, Options & Common CI Errors
export makes a shell variable visible to the programs the shell launches.
export is the line between a shell-local variable and an environment variable. The defining CI gotcha: an export in one step does NOT persist to the next step on most CI runners.
What it does
export marks a variable so it is passed into the environment of child processes the shell starts. Without export, a variable exists only in the current shell and is invisible to commands it runs.
Common usage
export NODE_ENV=production
VERSION=1.2.3; export VERSION
export PATH="$PWD/bin:$PATH"
export -p # list exported variables
# GitHub Actions: persist across steps
echo "MY_VAR=value" >> "$GITHUB_ENV"Options
| Item | What it does |
|---|---|
| export VAR=val | Set and export in one step |
| export VAR | Export an already-set variable |
| -p | Print all exported variables |
| -n VAR | Un-export but keep the variable |
Common errors in CI
The classic: export FOO=bar in one CI step does not reach the next step - each step is a fresh shell. On GitHub Actions write echo "FOO=bar" >> "$GITHUB_ENV"; on GitLab use a dotenv artifact or job-level variables. "export: not valid in this context" or "export: `=val': not a valid identifier" usually means a space around the = (NAME = val is wrong; use NAME=val). A var set without export is also invisible to sub-commands within the same step.