Jenkinsfile per branch - Commands & Configuration

Introduction

When working with multiple branches in a project, you may want each branch to have its own build and deployment steps. Using a Jenkinsfile per branch lets you customize the pipeline for each branch separately, so changes in one branch do not affect others.

When you want to test new features with different build steps before merging to main.

When different branches require different deployment environments or servers.

When you want to experiment with pipeline changes without impacting the main branch.

When you maintain long-lived branches with unique release processes.

When you want to keep branch-specific configurations close to the code.

Config File - Jenkinsfile

Jenkinsfile

pipeline {
    agent any
    stages {
        stage('Build') {
            steps {
                script {
                    if (env.BRANCH_NAME == 'main') {
                        echo 'Building main branch with production settings'
                        // Add main branch build steps here
                    } else if (env.BRANCH_NAME == 'develop') {
                        echo 'Building develop branch with staging settings'
                        // Add develop branch build steps here
                    } else {
                        echo "Building feature branch: ${env.BRANCH_NAME} with default settings"
                        // Add feature branch build steps here
                    }
                }
            }
        }
        stage('Test') {
            steps {
                echo 'Running tests'
                // Add test steps here
            }
        }
        stage('Deploy') {
            steps {
                script {
                    if (env.BRANCH_NAME == 'main') {
                        echo 'Deploying to production'
                        // Add production deploy steps
                    } else if (env.BRANCH_NAME == 'develop') {
                        echo 'Deploying to staging'
                        // Add staging deploy steps
                    } else {
                        echo 'Skipping deploy for feature branch'
                    }
                }
            }
        }
    }
}

This Jenkinsfile uses the env.BRANCH_NAME variable to detect the current branch. It runs different build and deploy steps depending on whether the branch is main, develop, or any other feature branch. This way, each branch can have its own pipeline logic inside a single Jenkinsfile.

Commands

Create and switch to the 'develop' branch to test branch-specific Jenkinsfile behavior.

Terminal

git checkout -b develop

Expected Output

Switched to a new branch 'develop'

Push the 'develop' branch to the remote repository so Jenkins can detect it and run the pipeline.

Terminal

git push origin develop

Expected Output

Enumerating objects: 5, done.

Counting objects: 100% (5/5), done.

Delta compression using up to 8 threads

Compressing objects: 100% (3/3), done.

Writing objects: 100% (3/3), 300 bytes | 300.00 KiB/s, done.

Total 3 (delta 2), reused 0 (delta 0)

remote: 

remote: Create a pull request for 'develop' on GitHub by visiting:

remote:      https://github.com/example/repo/pull/new/develop

remote: 

To https://github.com/example/repo.git

 * [new branch]      develop -> develop

Trigger the Jenkins pipeline manually for the 'develop' branch to see branch-specific pipeline steps.

Terminal

jenkins-cli build my-pipeline -p BRANCH_NAME=develop

Expected Output

[Pipeline] Start of Pipeline

Building develop branch with staging settings

Running tests

Deploying to staging

[Pipeline] End of Pipeline

Finished: SUCCESS

→

-p BRANCH_NAME=develop - Specifies the branch name parameter to simulate branch-specific pipeline execution

Trigger the Jenkins pipeline for a feature branch to verify it uses the default build and skips deployment.

Terminal

jenkins-cli build my-pipeline -p BRANCH_NAME=feature/new-ui

Expected Output

[Pipeline] Start of Pipeline

Building feature branch: feature/new-ui with default settings

Running tests

Skipping deploy for feature branch

[Pipeline] End of Pipeline

Finished: SUCCESS

→

-p BRANCH_NAME=feature/new-ui - Simulates running the pipeline on a feature branch

Key Concept

If you remember nothing else from this pattern, remember: use the branch name variable inside a single Jenkinsfile to customize pipeline steps per branch.

Common Mistakes

Creating separate Jenkinsfiles in each branch without a shared base.

This causes duplication and makes maintenance harder because changes must be repeated in all files.

Use one Jenkinsfile with conditional logic based on the branch name to keep pipeline code centralized.

Not pushing the branch to the remote repository before Jenkins runs the pipeline.

Jenkins cannot detect or build branches that do not exist on the remote, so the pipeline won't run.

Always push new branches to the remote repository so Jenkins can trigger builds.

Using incorrect or missing environment variables like BRANCH_NAME in the Jenkinsfile.

The pipeline will not detect the branch correctly and may run wrong steps or fail.

Use the built-in Jenkins environment variable 'env.BRANCH_NAME' to get the current branch name reliably.

Summary

Use a single Jenkinsfile with conditional logic based on the branch name to customize pipeline steps.

Push branches to the remote repository so Jenkins can detect and build them.

Trigger builds with the correct branch context to verify branch-specific pipeline behavior.

Practice

1. What is the main benefit of having a separate Jenkinsfile in each branch?

easy

A. It allows customizing the pipeline for each branch independently.

B. It forces all branches to use the same pipeline configuration.

C. It disables pipeline execution on branches without a Jenkinsfile.

D. It merges all branch pipelines into one global pipeline.

Solution

1. Step 1: Understand Jenkinsfile per branch concept

   Each branch can have its own Jenkinsfile, allowing different pipeline steps or settings per branch.

2. Step 2: Compare options

   It allows customizing the pipeline for each branch independently. correctly states the benefit. Options A, B, and D describe incorrect behaviors.

3. Final Answer:

   It allows customizing the pipeline for each branch independently. -> Option A

4. Quick Check:

   Separate Jenkinsfiles = branch-specific pipelines [OK]

Hint: Separate Jenkinsfiles mean separate pipelines per branch [OK]

Common Mistakes:

• Thinking one Jenkinsfile applies to all branches
• Assuming Jenkinsfile absence disables pipeline
• Believing pipelines merge automatically

2. Which of the following is the correct syntax to checkout from a specific branch in a multibranch pipeline?

easy

A. pipeline { agent any; stages { stage('Build') { steps { checkout([$class: 'GitSCM', branches: ['refs/heads/feature'], userRemoteConfigs: [[url: 'https://repo.git']]]) } } } }

B. pipeline { agent any; stages { stage('Build') { steps { git branch: 'main', url: 'https://repo.git' } } } }

C. pipeline { agent any; stages { stage('Build') { steps { load 'Jenkinsfile' } } } }

D. pipeline { agent any; stages { stage('Build') { steps { script { checkout scm } } } } }

Solution

1. Step 1: Identify correct syntax for branch checkout

   Using the git step with branch and url is the simplest correct way to checkout a specific branch.

2. Step 2: Analyze options

   The snippet using git branch: 'main', url: 'https://repo.git' is correct. The snippet using checkout([$class: 'GitSCM', branches: ['refs/heads/feature'], userRemoteConfigs: [[url: 'https://repo.git']]]) has invalid syntax for branches (expects list of maps like [[name: 'refs/heads/feature']]). The snippet using script { checkout scm } checks out the current SCM without specifying a branch. The snippet using load 'Jenkinsfile' loads a Groovy script but does not checkout a branch.

3. Final Answer:

   pipeline { agent any; stages { stage('Build') { steps { git branch: 'main', url: 'https://repo.git' } } } } -> Option B

4. Quick Check:

   Use git step with branch and url [OK]

Hint: Use git step with branch and url to specify branch [OK]

Common Mistakes:

• Using load to get Jenkinsfile instead of checkout
• Not specifying branch in checkout
• Confusing checkout scm with git step

3. Given this Jenkinsfile snippet inside a branch:

pipeline {
  agent any
  stages {
    stage('Test') {
      steps {
        script {
          if (env.BRANCH_NAME == 'main') {
            echo 'Deploying main branch'
          } else {
            echo 'Deploying feature branch'
          }
        }
      }
    }
  }
}

What will Jenkins print if the branch is named feature/login?

medium

A. No output

B. Deploying main branch

C. Deploying feature branch

D. Pipeline fails with error

Solution

1. Step 1: Understand branch name condition

   The script checks if env.BRANCH_NAME equals 'main'. If yes, it prints 'Deploying main branch', else 'Deploying feature branch'.

2. Step 2: Apply branch name 'feature/login'

   Since the branch is 'feature/login', it does not equal 'main', so the else branch runs printing 'Deploying feature branch'.

3. Final Answer:

   Deploying feature branch -> Option C

4. Quick Check:

   Branch name check leads to else output [OK]

Hint: Check branch name string exactly for condition [OK]

Common Mistakes:

• Assuming partial match triggers main branch output
• Confusing env.BRANCH_NAME with other variables
• Expecting no output if branch is not main

4. You have a Jenkinsfile in your feature branch but the pipeline fails with error: groovy.lang.MissingPropertyException: No such property: env for class. What is the likely cause?

medium

A. The env variable is used outside a script block.

B. The Jenkinsfile is missing the pipeline block.

C. The branch name is incorrect in the Jenkinsfile.

D. The Jenkinsfile is not committed to the branch.

Solution

1. Step 1: Understand env variable usage

   In declarative pipelines, env variables must be accessed inside a script block to use Groovy expressions.

2. Step 2: Analyze error cause

   The error indicates env is not recognized, likely because it is used outside a script block where Groovy code runs.

3. Final Answer:

   The env variable is used outside a script block. -> Option A

4. Quick Check:

   Use env only inside script blocks [OK]

Hint: Access env variables only inside script blocks [OK]

Common Mistakes:

• Using env directly in steps without script
• Assuming missing pipeline block causes env error
• Not committing Jenkinsfile to branch

5. You want to maintain a single Jenkinsfile in the main branch but customize pipeline steps for feature/* branches without creating Jenkinsfiles in each feature branch. Which approach is best?

hard

A. Configure Jenkins to ignore feature branches.

B. Create symbolic links to the main Jenkinsfile in each feature branch.

C. Use separate Jenkinsfiles in each feature branch and merge them manually.

D. Use when { branch 'feature/*' } conditions inside the Jenkinsfile to run different stages.

Solution

1. Step 1: Understand single Jenkinsfile with branch conditions

   You can use when { branch 'pattern' } in declarative pipelines to run stages only on matching branches.

2. Step 2: Evaluate options

   Use when { branch 'feature/*' } conditions inside the Jenkinsfile to run different stages. uses branch conditions inside one Jenkinsfile, which fits the requirement. Create symbolic links to the main Jenkinsfile in each feature branch. is not practical or supported. Use separate Jenkinsfiles in each feature branch and merge them manually. contradicts the goal of single Jenkinsfile. Configure Jenkins to ignore feature branches. ignores feature branches, not customizing them.

3. Final Answer:

   Use when { branch 'feature/*' } conditions inside the Jenkinsfile to run different stages. -> Option D

4. Quick Check:

   Branch conditions enable single Jenkinsfile customization [OK]

Hint: Use when branch conditions for per-branch steps [OK]

Common Mistakes:

• Trying to link Jenkinsfiles across branches
• Creating multiple Jenkinsfiles despite single file goal
• Ignoring feature branches instead of customizing