Environment directive in Jenkins - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

What is the output of this Jenkins pipeline environment variable?

Consider this Jenkins pipeline snippet:

pipeline {
  agent any
  environment {
    GREETING = 'Hello'
    TARGET = 'World'
  }
  stages {
    stage('Print') {
      steps {
        script {
          echo "${GREETING}, ${TARGET}!"
        }
      }
    }
  }
}

What will be printed in the console output?

Jenkins

pipeline {
  agent any
  environment {
    GREETING = 'Hello'
    TARGET = 'World'
  }
  stages {
    stage('Print') {
      steps {
        script {
          echo "${GREETING}, ${TARGET}!"
        }
      }
    }
  }
}

A Hello, ${TARGET}!

B ${GREETING}, ${TARGET}!

C Hello, World!

D GREETING, TARGET!

💡 Hint

Remember that environment variables defined in the environment block are accessible inside steps using ${VARIABLE_NAME}.

The environment directive sets variables that are accessible in the pipeline steps. Using ${GREETING} and ${TARGET} inside echo will substitute their values.

❓ Configuration

intermediate

Which environment directive syntax correctly sets a variable with a shell command output?

You want to set an environment variable CURRENT_DATE to the output of the shell command date in a Jenkins pipeline environment block. Which option correctly does this?

A

environment {
  CURRENT_DATE = "${sh 'date'}"
}

B

environment {
  CURRENT_DATE = sh(script: 'date', returnStdout: true).trim()
}

C

environment {
  CURRENT_DATE = "$(date)"
}

D

environment {
  CURRENT_DATE = sh('date')
}

💡 Hint

In Jenkins declarative pipeline, environment variables cannot directly run shell commands. You must use a script block or special syntax.

Only option B uses the correct syntax to run a shell command and assign its trimmed output to an environment variable in a declarative pipeline.

❓ Troubleshoot

advanced

Why does this environment variable not get set as expected?

Given this Jenkins pipeline snippet:

pipeline {
  agent any
  environment {
    PATH = '/custom/path'
  }
  stages {
    stage('Check') {
      steps {
        sh 'echo $PATH'
      }
    }
  }
}

The output shows only the default PATH, not '/custom/path'. Why?

Jenkins

pipeline {
  agent any
  environment {
    PATH = '/custom/path'
  }
  stages {
    stage('Check') {
      steps {
        sh 'echo $PATH'
      }
    }
  }
}

A The environment directive overrides PATH, but the shell step resets PATH to default for security.

B The shell step runs in a separate shell that does not inherit Jenkins environment variables.

C The PATH variable is overridden but the shell uses a cached PATH ignoring Jenkins variables.

D The environment directive overrides PATH only inside the Jenkins process, not the shell environment.

💡 Hint

Some environment variables like PATH are treated specially by Jenkins for security reasons.

Jenkins resets PATH in shell steps to avoid security risks. Overriding PATH in environment does not affect shell steps unless explicitly handled.

🔀 Workflow

advanced

How to pass environment variables between stages in a declarative pipeline?

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

A Use the stash/unstash steps to pass environment variables between stages.

B Set the variable in one stage's environment block and it will automatically be available in later stages.

C Use script block to set a global variable and then assign it to environment in later stages.

D Set the variable in the environment block at pipeline level so all stages can access it.

💡 Hint

Environment variables defined at the pipeline level are global to all stages.

Only environment variables defined at the pipeline level environment block are available in all stages. Stage-level environment blocks are local to that stage.

✅ Best Practice

expert

What is the best practice for securely handling sensitive environment variables in Jenkins pipelines?

You need to use a secret API key in your Jenkins pipeline environment. Which method is the best practice to handle this securely?

A Store the API key in Jenkins credentials and use the credentials binding plugin to inject it as an environment variable.

B Hardcode the API key in the environment block of the Jenkinsfile for easy access.

C Store the API key in a plain text file in the repository and read it during the pipeline.

D Pass the API key as a parameter to the pipeline and print it in the logs for debugging.

💡 Hint

Avoid exposing secrets in code or logs. Use Jenkins built-in secure storage.

Using Jenkins credentials and credentials binding plugin securely injects secrets as environment variables without exposing them in code or logs.

Practice

1. What is the main purpose of the environment directive in a Jenkins pipeline?

easy

A. To define variables that can be used throughout the pipeline steps

B. To specify the build agent or node where the pipeline runs

C. To set the pipeline's timeout duration

D. To declare the stages of the pipeline

Solution

1. Step 1: Understand the role of environment directive

   The environment directive is used to set variables accessible in all pipeline steps.

2. Step 2: Compare with other pipeline directives

   Other directives like agent set the build node, and stages define pipeline stages, not environment variables.

3. Final Answer:

   To define variables that can be used throughout the pipeline steps -> Option A

4. Quick Check:

   Environment directive = set variables [OK]

Hint: Environment directive sets variables for all steps [OK]

Common Mistakes:

• Confusing environment with agent directive
• Thinking environment sets pipeline stages
• Assuming environment controls timeout

2. Which of the following is the correct syntax to set an environment variable GREETING with value Hello in a declarative Jenkins pipeline?

easy

A. environment { GREETING 'Hello' }

B. environment { GREETING: Hello }

C. environment { GREETING = Hello }

D. environment { GREETING = "Hello" }

Solution

1. Step 1: Recall environment variable syntax

   In Jenkins declarative pipelines, environment variables are set using environment { VAR = "value" } with quotes around string values.

2. Step 2: Check each option

   environment { GREETING = "Hello" } uses = with double quotes correctly.
   environment { GREETING: Hello } uses colon with unquoted Hello, syntax error (unresolved variable).
   environment { GREETING = Hello } misses quotes, syntax error.
   environment { GREETING 'Hello' } lacks assignment operator, syntax error.

3. Final Answer:

   environment { GREETING = "Hello" } -> Option D

4. Quick Check:

   Use double quotes for string values in environment [OK]

Hint: Use double quotes around string values in environment [OK]

Common Mistakes:

• Using colon instead of equals sign
• Omitting quotes around string values
• Using unquoted strings causing syntax errors

3. Given this Jenkins pipeline snippet:

pipeline {
  agent any
  environment {
    PATH = "/usr/local/bin"
    MESSAGE = "Build started"
  }
  stages {
    stage('Print') {
      steps {
        echo "$MESSAGE"
        sh 'echo $PATH'
      }
    }
  }
}

What will be the output when the Print stage runs?

medium

A. Build started
/usr/local/bin

B. $MESSAGE
$PATH

C. Build started
$PATH

D. Syntax error due to environment variables

Solution

1. Step 1: Understand environment variable usage

   The environment directive sets MESSAGE and PATH variables accessible in steps.

2. Step 2: Check echo and shell commands

   echo "$MESSAGE" prints the value of MESSAGE, which is "Build started". The shell command sh 'echo $PATH' prints the PATH variable value "/usr/local/bin".

3. Final Answer:

   Build started /usr/local/bin -> Option A

4. Quick Check:

   Environment variables expand correctly in echo and sh [OK]

Hint: Environment variables expand in echo and shell commands [OK]

Common Mistakes:

• Expecting literal variable names instead of values
• Confusing shell and Groovy variable syntax
• Assuming syntax error without cause

4. You wrote this environment block in your Jenkins pipeline:

environment {
  SECRET_KEY = secret123
}

But the pipeline fails with a syntax error. What is the most likely cause?

medium

A. Using an invalid variable name SECRET_KEY

B. Environment block must be inside a stage

C. Missing quotes around the string value

D. SECRET_KEY cannot contain numbers

Solution

1. Step 1: Check environment variable value syntax

   String values in environment variables must be quoted, e.g., SECRET_KEY = "secret123".

2. Step 2: Validate other options

   Variable names with underscores and numbers are valid. Environment block can be at pipeline level. Numbers in variable names are allowed.

3. Final Answer:

   Missing quotes around the string value -> Option C

4. Quick Check:

   Quote string values in environment variables [OK]

Hint: Always quote string values in environment directive [OK]

Common Mistakes:

• Forgetting quotes around strings
• Thinking variable names can't have underscores
• Placing environment block incorrectly

5. You want to set an environment variable VERSION dynamically based on a shell command output in a Jenkins declarative pipeline. Which approach correctly sets VERSION for use in later stages?

hard

A. Use environment { VERSION = sh(script: 'git describe --tags', returnStdout: true).trim() } directly in pipeline

B. Set VERSION inside a script block and use env.VERSION = ...

C. Declare VERSION as a parameter and assign shell output to it

D. Use environment { VERSION = "git describe --tags" } to run the command

Solution

1. Step 1: Understand environment directive limitations

   The environment directive cannot run shell commands directly; it only sets static values.

2. Step 2: Use script block to assign dynamic value

   Inside a script block, you can run shell commands and assign the output to env.VERSION for later use.

3. Step 3: Evaluate other options

   Use environment { VERSION = sh(script: 'git describe --tags', returnStdout: true).trim() } directly in pipeline tries to run shell in environment block which is invalid. Declare VERSION as a parameter and assign shell output to it misuses parameters. Use environment { VERSION = "git describe --tags" } to run the command assigns command string literally.

4. Final Answer:

   Set VERSION inside a script block and use env.VERSION = ... -> Option B

5. Quick Check:

   Dynamic env vars need script block assignment [OK]

Hint: Use script block to set dynamic environment variables [OK]

Common Mistakes:

• Trying to run shell commands directly in environment block
• Confusing parameters with environment variables
• Assigning command strings instead of output