env and printenv: Inspect the Environment in CI
env prints the current environment variables and can launch a command with variables added, removed, or cleared, which is essential for debugging CI configuration.
Most "works locally, fails in CI" bugs are environment differences. env shows exactly what variables the step sees and lets you reproduce or strip the environment to isolate the cause.
What it does
env with no arguments prints every exported environment variable. Given NAME=value cmd it runs cmd with that variable set; -u NAME removes one; -i starts from an empty environment. printenv is the simpler read-only sibling for printing one or all variables.
Common usage
env | sort # all variables, sorted
printenv PATH # one variable
env -i PATH=/usr/bin ./script # run with a clean, minimal env
env DEBUG=1 NODE_ENV=test npm testOptions
| Form / flag | What it does |
|---|---|
| env | Print all environment variables |
| env NAME=val cmd | Run cmd with NAME set |
| -u NAME | Run with NAME removed |
| -i | Start from an empty environment |
| printenv [NAME] | Print all, or one variable |
| -0 | NUL-separate output (safe for newlines in values) |
In CI
Print env | sort early to confirm a variable is actually set, but remember most CI systems mask known secret values in logs, so a secret may show as ***; an empty value means it was never injected (often a typo in the variable name or a secret not exposed to forks). Reproduce a clean-environment bug with env -i to find which variable a command depends on.
Common errors in CI
A variable that is set in one step but empty in the next is normal: each CI step usually runs in a fresh shell, so exports do not persist (use the platform’s environment-file mechanism instead). "env: ‘node’: No such file or directory" from a shebang like #!/usr/bin/env node means node is not on PATH for that step. Secrets printed as *** are masked, not missing.