What Is a Pipeline Variable? Passing Values Through a Run
A pipeline variable is a named value that jobs and steps can read during a run, used to configure behavior without hard-coding values.
Pipelines need to know things: which environment to deploy to, what version to tag, which API endpoint to hit. Pipeline variables carry those values into your jobs and steps. They keep configuration out of your scripts, let one pipeline behave differently per branch or environment, and provide a controlled way to inject secrets.
Where variables come from
- Built-in: the platform sets values like commit SHA and branch name.
- Defined: you declare variables in the pipeline file.
- Stored: secrets and config set in the project or org settings.
- Computed: a step writes a value other steps then read.
Scope and precedence
Variables can be scoped to the whole pipeline, a single job, or one step. Narrower scopes usually override wider ones, so a job-level variable beats a pipeline-level one of the same name. Knowing the precedence avoids surprises.
A quick example
In GitHub Actions you read a variable as ${{ vars.DEPLOY_ENV }} or an environment variable as ${ENV_NAME} inside a shell step. Setting env: ENV_NAME: staging on a job makes it visible to every step in that job.
Variables vs secrets
Plain variables are fine for non-sensitive config. Secrets (API keys, tokens) are a special kind of variable: encrypted at rest and masked in logs. Never put a credential in a plain variable, and never echo a secret to the log.
Passing values between jobs
Steps in a job share variables freely, but jobs are isolated. To send a value from one job to another you use job outputs, which the platform passes along the dependency edge. That is how a build job can hand a version string to a deploy job.
Key takeaways
- A pipeline variable is a named value jobs and steps read at runtime.
- Variables can be built-in, defined, stored, or computed during the run.
- Use secrets (not plain variables) for credentials; pass cross-job values via outputs.