Branch-specific pipeline behavior in Jenkins - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

Output of branch-specific Jenkins pipeline snippet

Given this Jenkins pipeline snippet, what will be printed when the branch is 'feature/new-ui'?

Jenkins

pipeline {
  agent any
  stages {
    stage('Build') {
      steps {
        script {
          if (env.BRANCH_NAME == 'main') {
            echo 'Building main branch'
          } else {
            echo "Building branch: ${env.BRANCH_NAME}"
          }
        }
      }
    }
  }
}

A Building main branch

B No output

C Error: BRANCH_NAME not defined

D Building branch: feature/new-ui

💡 Hint

Check the condition comparing env.BRANCH_NAME to 'main'.

The pipeline checks if the branch name is exactly 'main'. Since the branch is 'feature/new-ui', it prints the else branch message with the branch name.

❓ Configuration

intermediate

Correct Jenkinsfile syntax for branch-specific stage

Which Jenkinsfile snippet correctly runs the 'Deploy' stage only on the 'release' branch?

A

stage('Deploy') {
  when {
    branch 'release'
  }
  steps {
    echo 'Deploying release branch'
  }
}

B

stage('Deploy') {
  when {
    environment name: 'BRANCH_NAME', value: 'release'
  }
  steps {
    echo 'Deploying release branch'
  }
}

C

stage('Deploy') {
  if (env.BRANCH_NAME == 'release') {
    steps {
      echo 'Deploying release branch'
    }
  }
}

D

stage('Deploy') {
  when {
    branch == 'release'
  }
  steps {
    echo 'Deploying release branch'
  }
}

💡 Hint

Use the 'when' directive with 'branch' condition.

Option A uses the correct 'when' syntax with 'branch' condition. Option A uses environment condition incorrectly. Option A has invalid syntax mixing 'if' inside stage. Option A uses invalid 'branch ==' syntax.

❓ Troubleshoot

advanced

Why does the Jenkins pipeline stage run on all branches despite 'when' condition?

A Jenkins pipeline has this stage: stage('Test') { when { branch 'develop' } steps { echo 'Running tests' } } But the stage runs on 'feature/login' branch too. What is the most likely cause?

A The pipeline is running in a multibranch job but BRANCH_NAME is not set properly

B The 'branch' condition is case-sensitive and branch name is 'Develop' with uppercase D

C The 'when' directive is ignored if placed inside 'steps' block

D The 'when' condition requires 'expression' block to work

💡 Hint

Check environment variables in multibranch pipelines.

In multibranch pipelines, the 'branch' condition depends on the BRANCH_NAME environment variable. If it's not set correctly, the condition always passes. Case sensitivity is not the issue here.

🔀 Workflow

advanced

Order of execution in branch-specific Jenkins pipeline

Given this Jenkins pipeline snippet, what is the order of printed messages when running on branch 'hotfix'?

Jenkins

pipeline {
  agent any
  stages {
    stage('Init') {
      steps {
        echo 'Init stage'
      }
    }
    stage('Build') {
      when {
        branch 'main'
      }
      steps {
        echo 'Build stage'
      }
    }
    stage('Test') {
      when {
        not {
          branch 'main'
        }
      }
      steps {
        echo 'Test stage'
      }
    }
  }
}

A 1,2,3

B 3,1

C 1,3

D 2,3

💡 Hint

Check which stages run on 'hotfix' branch.

'Init' stage always runs. 'Build' runs only on 'main' branch, so skipped. 'Test' runs on all branches except 'main', so it runs on 'hotfix'.

✅ Best Practice

expert

Best practice for managing branch-specific Jenkins pipeline logic

Which approach is best to maintain complex branch-specific logic in Jenkins pipelines for multiple branches with different build steps?

A Create separate Jenkinsfiles per branch and configure jobs to use the correct file

B Use a shared library with functions that handle branch-specific logic called from a simple Jenkinsfile

C Use multiple 'when' conditions inside a single Jenkinsfile with complex nested logic

D Use environment variables to disable stages manually per branch

💡 Hint

Think about maintainability and code reuse.

Using a shared library centralizes branch-specific logic, making the Jenkinsfile simpler and easier to maintain. Multiple 'when' conditions can get messy. Separate Jenkinsfiles increase duplication. Manual environment variable toggling is error-prone.