Environment variables in builds in Jenkins - Step-by-Step Execution

Process Flow - Environment variables in builds

Start Build

↓

Load Global Env Vars

↓

Load Job-Specific Env Vars

↓

Execute Build Steps

↓

Use Env Vars in Scripts

↓

Build Completes

This flow shows how Jenkins loads environment variables globally and per job, then uses them during build steps.

Execution Sample

Jenkins

pipeline {
  agent any
  environment {
    GREETING = 'Hello'
  }
  stages {
    stage('Build') {
      steps {
        echo "${GREETING}, Jenkins!"
      }
    }
  }
}

A Jenkins pipeline that sets an environment variable GREETING and prints it during the build.

Process Table

Step	Action	Environment Variables Loaded	Command Executed	Output
1	Start Build	{}	N/A	Build started
2	Load Global Env Vars	{"PATH":"/usr/bin","JAVA_HOME":"/usr/lib/jvm"}	N/A	Global vars loaded
3	Load Job-Specific Env Vars	{"PATH":"/usr/bin","JAVA_HOME":"/usr/lib/jvm","GREETING":"Hello"}	N/A	Job vars loaded
4	Execute Build Step	{"PATH":"/usr/bin","JAVA_HOME":"/usr/lib/jvm","GREETING":"Hello"}	echo "${GREETING}, Jenkins!"	Hello, Jenkins!
5	Build Completes	{"PATH":"/usr/bin","JAVA_HOME":"/usr/lib/jvm","GREETING":"Hello"}	N/A	Build finished successfully

💡 Build completes after executing all steps with environment variables available.

Status Tracker

Variable	Start	After Global Load	After Job Load	Final
PATH	undefined	/usr/bin	/usr/bin	/usr/bin
JAVA_HOME	undefined	/usr/lib/jvm	/usr/lib/jvm	/usr/lib/jvm
GREETING	undefined	undefined	Hello	Hello

Key Moments - 3 Insights

Why does GREETING only appear after job-specific env vars load?

Because GREETING is defined in the job environment block, it is not available until the job-specific variables load step (see execution_table row 3).

Can global environment variables be overwritten by job-specific ones?

Yes, job-specific environment variables can overwrite global ones. The variable tracker shows the final values after job load (see variable_tracker).

Why does the echo command print 'Hello, Jenkins!'?

Because the GREETING variable is set to 'Hello' before the build step runs, so the echo command expands it correctly (see execution_table row 4).

Visual Quiz - 3 Questions

Look at the execution table, what is the value of GREETING at step 2?

A Hello

B /usr/bin

C undefined

D Jenkins

💡 Hint

Check the 'Environment Variables Loaded' column at step 2 in the execution_table.

At which step does the build print the greeting message?

A Step 1

B Step 4

C Step 3

D Step 5

💡 Hint

Look for the 'Command Executed' and 'Output' columns in the execution_table.

If the GREETING variable was removed from the job environment, what would the echo output be at step 4?

A ", Jenkins!"

B "Hello, Jenkins!"

C "${GREETING}, Jenkins!"

D "undefined, Jenkins!"

💡 Hint

Consider what happens when a variable is not defined but referenced in a shell echo command.

Concept Snapshot

Jenkins loads environment variables globally first, then job-specific ones.
Variables set in the environment block are available during build steps.
Use ${VAR_NAME} syntax to access variables in shell commands.
Job variables can overwrite global variables.
Environment variables help customize builds without changing code.

Full Transcript

This visual execution shows how Jenkins handles environment variables during a build. First, the build starts with no variables. Then global environment variables like PATH and JAVA_HOME load. Next, job-specific variables such as GREETING are added. During the build step, the echo command uses the GREETING variable to print a message. Finally, the build completes successfully with all variables available. The variable tracker confirms how variables appear and change. Key points include when variables become available and how they affect commands. The quiz tests understanding of variable values at different steps and the effect of missing variables.

Practice

1. What is the main purpose of environment variables in Jenkins builds?

easy

A. To write the build script itself

B. To display the build logs on the screen

C. To store data like secrets or settings without changing the build code

D. To install Jenkins plugins automatically

Solution

1. Step 1: Understand environment variables role

   Environment variables hold data such as secrets, settings, or dynamic values needed during the build without modifying the build code.

2. Step 2: Identify the correct purpose in Jenkins context

   Jenkins uses environment variables to pass information to builds safely and flexibly.

3. Final Answer:

   To store data like secrets or settings without changing the build code -> Option C

4. Quick Check:

   Environment variables = store build data [OK]

Hint: Environment variables hold build data, not code or logs [OK]

Common Mistakes:

• Confusing environment variables with build scripts
• Thinking environment variables show logs
• Assuming environment variables install plugins

2. Which syntax correctly defines an environment variable named VERSION with value 1.0 in a Jenkins pipeline?

easy

A. environment { VERSION = '1.0' }

B. environment { 'VERSION' = '1.0' }

C. environment { VERSION: '1.0'; }

D. environment { VERSION == '1.0' }

Solution

1. Step 1: Recall Jenkins pipeline environment syntax

   In Jenkins declarative pipelines, environment variables are defined using environment { VAR_NAME = 'value' } syntax.

2. Step 2: Identify correct syntax

   environment { VERSION = '1.0' } uses = which is the correct syntax inside the environment block.

3. Final Answer:

   environment { VERSION = '1.0' } -> Option A

4. Quick Check:

   Use equals sign for key-value in environment block [OK]

Hint: Use = not colon or double equals in environment block [OK]

Common Mistakes:

• Using colon instead of equals sign
• Using double equals which is invalid
• Putting quotes around variable name incorrectly

3. Given this Jenkins pipeline snippet:

pipeline {
  environment {
    BUILD_TYPE = 'release'
  }
  stages {
    stage('Print') {
      steps {
        echo "Build type is: ${BUILD_TYPE}"
      }
    }
  }
}

What will be printed during the build?

medium

A. Error: BUILD_TYPE not defined

B. Build type is: ${BUILD_TYPE}

C. Build type is:

D. Build type is: release

Solution

1. Step 1: Understand environment variable usage in pipeline

   The environment block sets BUILD_TYPE to 'release'. The echo step uses ${BUILD_TYPE} to access this variable.

2. Step 2: Predict output of echo command

   The variable is replaced by its value, so the output will be 'Build type is: release'.

3. Final Answer:

   Build type is: release -> Option D

4. Quick Check:

   Variable expands to value in echo [OK]

Hint: Variables in ${} expand to their values in echo [OK]

Common Mistakes:

• Expecting literal ${BUILD_TYPE} printed
• Thinking variable is empty if not exported
• Assuming error if variable is defined in environment block

4. You wrote this Jenkins pipeline snippet:

pipeline {
  environment {
    API_KEY = SECRET_KEY
  }
  stages {
    stage('Test') {
      steps {
        echo "API key is ${API_KEY}"
      }
    }
  }
}

But the build fails with an error about SECRET_KEY. What is the problem?

medium

A. You must quote the value: API_KEY = "$SECRET_KEY"

B. SECRET_KEY is not defined in Jenkins environment

C. You cannot use environment variables inside environment block directly

D. You should use single quotes instead of double quotes

Solution

1. Step 1: Analyze variable usage in environment block

   The environment block tries to assign API_KEY the value of SECRET_KEY. This requires SECRET_KEY to be defined in Jenkins environment or injected.

2. Step 2: Identify cause of error

   If SECRET_KEY is not defined anywhere, Jenkins cannot resolve it, causing the build to fail.

3. Final Answer:

   SECRET_KEY is not defined in Jenkins environment -> Option B

4. Quick Check:

   Undefined variables cause build errors [OK]

Hint: Ensure referenced env vars exist before using them [OK]

Common Mistakes:

• Assuming quoting fixes undefined variable errors
• Thinking environment block cannot use variables at all
• Using single quotes which prevent variable expansion

5. You want to pass a dynamic build number as an environment variable BUILD_NUM to your Jenkins pipeline and print it. Which snippet correctly achieves this?

hard

A. environment { BUILD_NUM = "${env.BUILD_NUMBER}" }

B. environment { BUILD_NUM == "${env.BUILD_NUMBER}" }

C. environment { BUILD_NUM = env.BUILD_NUMBER; }

D. environment { BUILD_NUM: env.BUILD_NUMBER; }

Solution

1. Step 1: Recall correct syntax for environment variables with dynamic values

   In Jenkins declarative pipelines, environment variables are defined with equals sign syntax and string values. To use a dynamic value like env.BUILD_NUMBER, it must be inside quotes and referenced with ${}.

2. Step 2: Identify correct option

   environment { BUILD_NUM = "${env.BUILD_NUMBER}" } uses BUILD_NUM = "${env.BUILD_NUMBER}" which correctly sets the environment variable to the current build number.

3. Final Answer:

   environment { BUILD_NUM = "${env.BUILD_NUMBER}" } -> Option A

4. Quick Check:

   Use equals sign and ${} for dynamic env vars [OK]

Hint: Use equals sign and ${env.VAR} inside quotes for dynamic vars [OK]

Common Mistakes:

• Using double equals instead of equals sign
• Not quoting the dynamic variable
• Omitting ${} around env variable