Environment variables in builds in Jenkins - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

Jenkins environment variable usage in shell step

In a Jenkins pipeline, you have set an environment variable MY_VAR with value hello. What will be the output of the following shell step?

sh 'echo $MY_VAR'

Jenkins

pipeline {
  agent any
  environment {
    MY_VAR = 'hello'
  }
  stages {
    stage('Print') {
      steps {
        sh 'echo $MY_VAR'
      }
    }
  }
}

A SyntaxError

B $MY_VAR

C null

D hello

💡 Hint

Remember how shell variables are accessed inside shell steps in Jenkins.

In Jenkins shell steps, environment variables are accessed using the shell syntax with a dollar sign, so $MY_VAR expands to 'hello'.

🧠 Conceptual

intermediate

Scope of environment variables in Jenkins pipeline

Which statement about environment variables in Jenkins declarative pipelines is true?

A Environment variables set inside a <code>script</code> block are automatically global.

B Environment variables set in the <code>environment</code> block are available to all stages and steps.

C Environment variables cannot be accessed in <code>sh</code> steps.

D Environment variables must be declared in the Jenkins system configuration to be used in pipelines.

💡 Hint

Think about where you declare environment variables in a declarative pipeline.

The environment block in a declarative pipeline sets variables that are available throughout the pipeline's stages and steps.

❓ Troubleshoot

advanced

Why does a Jenkins shell step not see a custom environment variable?

You set an environment variable MY_VAR inside a script block using env.MY_VAR = 'test'. But when you run sh 'echo $MY_VAR' in the next step, it prints empty. Why?

A Because environment variables set in <code>script</code> blocks are not automatically exported to shell steps.

B Because <code>sh</code> steps cannot access any environment variables.

C Because <code>env.MY_VAR</code> must be declared in the <code>environment</code> block to be visible.

D Because shell steps require variables to be passed as parameters explicitly.

💡 Hint

Consider how Jenkins passes environment variables to shell steps.

Setting env.MY_VAR inside a script block changes the variable for the Groovy environment but does not export it to the shell environment automatically.

🔀 Workflow

advanced

Passing environment variables between Jenkins pipeline stages

You want to set an environment variable VERSION in one stage and use it in a later stage. Which approach works correctly?

A Set <code>env.VERSION = '1.0'</code> in the first stage inside a <code>script</code> block; it will be available in later stages.

B Use the <code>environment</code> block at the pipeline level and update <code>VERSION</code> dynamically in the first stage.

C Write the variable to a file in the first stage and read it in the next stage.

D Set <code>VERSION</code> as a global variable in Jenkins system configuration.

💡 Hint

Think about how Jenkins pipeline stages run in separate processes.

Each stage runs in a separate process, so environment variables set in one stage do not persist automatically. Writing to a file and reading it later is a common way to share data.

✅ Best Practice

expert

Secure handling of sensitive environment variables in Jenkins builds

Which is the best practice to handle sensitive environment variables like passwords in Jenkins pipelines?

A Store sensitive variables in Jenkins Credentials and inject them using the <code>credentials()</code> helper.

B Hardcode sensitive variables directly in the <code>environment</code> block for easy access.

C Print sensitive variables in console logs for debugging purposes.

D Store sensitive variables in plain text files inside the workspace.

💡 Hint

Think about security and Jenkins features for secrets.

Jenkins Credentials plugin securely stores secrets and allows injecting them without exposing in logs or code.

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