What Is an Environment Variable in CI?
An environment variable in CI is a named value made available to your job's processes - used to configure behavior without hard-coding it.
Builds and scripts read configuration from the environment: which registry to use, which build mode, feature flags. CI lets you define these variables at several levels so the same workflow behaves correctly across branches, environments, and matrix cells.
How they are set
You can set variables at the workflow, job, or step level, and read them in scripts as $NAME. Matrix values and computed outputs commonly flow in as environment variables too.
A small example
Setting env: NODE_ENV: production at the job level makes every step in that job build in production mode. A single step can override it with its own env: block for a one-off test build.
Variables vs secrets
Plain environment variables are not sensitive and appear in logs. Secrets are encrypted and masked. Configuration like a build mode is a variable; a token is a secret - do not put credentials in plain variables.
Precedence and scope
- Step-level values override job-level, which override workflow-level.
- Variables are scoped to the run that sets them - they do not persist.
- Some platforms have org or repo "variables" for non-secret shared config.
Passing values between steps
A variable set with plain export in one step does not survive to the next step, which runs a fresh shell. To persist a value, write it to the platform's environment file (for example appending to $GITHUB_ENV) instead.
Key takeaways
- An environment variable configures a job's processes by name.
- Variables are for non-sensitive config; secrets are for credentials.
- Narrower scopes override broader ones, and values do not persist by default.