Parameterized builds in Jenkins - Commands & Configuration

Introduction

Sometimes you want to run the same Jenkins job but with different inputs each time. Parameterized builds let you give values like names or versions when you start the job, so it can behave differently without changing the job itself.

When you want to build the same project but for different environments like testing or production.

When you need to pass a version number or feature flag to your build without editing the job.

When you want to run a deployment job with different server addresses each time.

When you want to trigger a job manually and choose options like debug mode or release mode.

When you want to reuse one job for multiple similar tasks by changing parameters.

Config File - Jenkinsfile

Jenkinsfile

pipeline {
  agent any
  parameters {
    string(name: 'BRANCH_NAME', defaultValue: 'main', description: 'Git branch to build')
    booleanParam(name: 'RUN_TESTS', defaultValue: true, description: 'Run tests after build')
  }
  stages {
    stage('Checkout') {
      steps {
        echo "Checking out branch ${params.BRANCH_NAME}"
        git branch: "${params.BRANCH_NAME}", url: 'https://github.com/example/my-app.git'
      }
    }
    stage('Build') {
      steps {
        echo 'Building the project'
      }
    }
    stage('Test') {
      when {
        expression { return params.RUN_TESTS }
      }
      steps {
        echo 'Running tests'
      }
    }
  }
}

This Jenkinsfile defines a pipeline with two parameters: BRANCH_NAME to choose which Git branch to build, and RUN_TESTS to decide if tests should run.

The Checkout stage uses the branch parameter to get the right code. The Test stage runs only if RUN_TESTS is true.

Commands

This command starts the Jenkins job named 'my-pipeline' and sets the parameter BRANCH_NAME to 'feature-xyz' and RUN_TESTS to false, so it builds that branch and skips tests.

Terminal

jenkins-jobs build my-pipeline -p BRANCH_NAME=feature-xyz -p RUN_TESTS=false

Expected Output

[Pipeline] Start of Pipeline

[Pipeline] echo

Checking out branch feature-xyz

[Pipeline] git

Cloning repository https://github.com/example/my-app.git

[Pipeline] echo

Building the project

[Pipeline] End of Pipeline

Finished: SUCCESS

→

-p BRANCH_NAME=feature-xyz - Sets the Git branch to build

→

-p RUN_TESTS=false - Disables running tests

This command runs the same job but builds the main branch and runs tests because RUN_TESTS is true.

Terminal

jenkins-jobs build my-pipeline -p BRANCH_NAME=main -p RUN_TESTS=true

Expected Output

[Pipeline] Start of Pipeline

[Pipeline] echo

Checking out branch main

[Pipeline] git

Cloning repository https://github.com/example/my-app.git

[Pipeline] echo

Building the project

[Pipeline] echo

Running tests

[Pipeline] End of Pipeline

Finished: SUCCESS

→

-p BRANCH_NAME=main - Sets the Git branch to build

→

-p RUN_TESTS=true - Enables running tests

Key Concept

If you remember nothing else from parameterized builds, remember: parameters let you change what a Jenkins job does each time you run it without changing the job itself.

Common Mistakes

Not defining parameters in the Jenkinsfile but trying to pass them when running the job

Jenkins won't recognize parameters that are not declared, so the job ignores them or fails.

Always declare all parameters inside the Jenkinsfile under the parameters block before using them.

Passing parameters with wrong names or typos in the command line

Jenkins will not match the parameter and will use default values or error out.

Double-check parameter names exactly as declared in the Jenkinsfile when passing them.

Using parameters but not referencing them in the pipeline steps

Parameters have no effect if the pipeline code does not use them, so the build behaves the same every time.

Use parameters with the syntax params.PARAMETER_NAME inside the Jenkinsfile to control behavior.

Summary

Define parameters in the Jenkinsfile to let users provide inputs when starting a build.

Use the params object inside pipeline steps to access parameter values.

Run the job with the jenkins-jobs CLI and pass parameters with -p flags to customize each build.

Practice

1.

What is the main purpose of parameterized builds in Jenkins?

easy

A. To allow users to input values that customize the build process

B. To automatically deploy builds to production

C. To schedule builds at specific times

D. To monitor server health during builds

Solution

1. Step 1: Understand parameterized builds concept

   Parameterized builds let users provide inputs that change how the build runs.

2. Step 2: Identify the main purpose

   The main goal is to customize the build without changing the job code.

3. Final Answer:

   To allow users to input values that customize the build process -> Option A

4. Quick Check:

   Parameterized builds = user inputs [OK]

Hint: Think: 'How do I change build behavior without editing code?' [OK]

Common Mistakes:

• Confusing parameterized builds with scheduling
• Thinking parameters deploy builds automatically
• Mixing monitoring with build customization

2.

Which of the following is the correct syntax to define a string parameter named ENV in a Jenkins pipeline?

parameters {
    ?
}

easy

A. paramString('ENV', 'dev', 'Environment')

B. string(name: 'ENV', defaultValue: 'dev', description: 'Environment')

C. stringParam('ENV', 'dev', 'Environment')

D. parameterString(name='ENV', default='dev')

Solution

1. Step 1: Recall Jenkins pipeline parameter syntax

   Jenkins uses string(name: '', defaultValue: '', description: '') inside parameters block.

2. Step 2: Match correct syntax

   string(name: 'ENV', defaultValue: 'dev', description: 'Environment') matches the correct syntax exactly.

3. Final Answer:

   string(name: 'ENV', defaultValue: 'dev', description: 'Environment') -> Option B

4. Quick Check:

   Correct parameter syntax = string(name: 'ENV', defaultValue: 'dev', description: 'Environment') [OK]

Hint: Remember: 'string' with named args inside parameters block [OK]

Common Mistakes:

• Using incorrect function names like stringParam
• Missing named arguments or using wrong argument names
• Confusing parameter syntax with freestyle job parameters

3.

Given this Jenkins pipeline snippet, what will be printed if the build is started with parameter BRANCH=feature?

pipeline {
  agent any
  parameters {
    string(name: 'BRANCH', defaultValue: 'main', description: 'Git branch')
  }
  stages {
    stage('Print Branch') {
      steps {
        echo "Building branch: ${params.BRANCH}"
      }
    }
  }
}

medium

A. Building branch: main

B. Error: BRANCH parameter not found

C. Building branch: feature

D. Building branch: ${params.BRANCH}

Solution

1. Step 1: Understand parameter usage in pipeline

   The parameter BRANCH has default 'main' but can be overridden at build start.

2. Step 2: Check what happens when build starts with BRANCH=feature

   The value 'feature' replaces default, so params.BRANCH is 'feature'.

3. Final Answer:

   Building branch: feature -> Option C

4. Quick Check:

   Parameter override prints new value [OK]

Hint: Parameter value at build start overrides default [OK]

Common Mistakes:

• Assuming default value always prints
• Thinking variable is not replaced in echo
• Confusing parameter name with environment variables

4.

Identify the error in this Jenkins pipeline snippet that defines a boolean parameter:

pipeline {
  agent any
  parameters {
    booleanParam(name: 'DEPLOY', default: true, description: 'Deploy after build?')
  }
  stages {
    stage('Check Deploy') {
      steps {
        script {
          if (params.DEPLOY) {
            echo 'Deploying...'
          } else {
            echo 'Skipping deploy'
          }
        }
      }
    }
  }
}

medium

A. The 'script' block is not allowed inside 'steps'

B. The parameter name should be 'boolean' not 'booleanParam'

C. The if condition should use 'params.deploy' in lowercase

D. The default value key should be 'defaultValue' not 'default'

Solution

1. Step 1: Check boolean parameter syntax

   Jenkins expects booleanParam(name: '', defaultValue: true/false, description: '').

2. Step 2: Identify incorrect key

   The snippet uses default instead of defaultValue, causing syntax error.

3. Final Answer:

   The default value key should be 'defaultValue' not 'default' -> Option D

4. Quick Check:

   Boolean param uses defaultValue key [OK]

Hint: Use 'defaultValue' for parameters, not 'default' [OK]

Common Mistakes:

• Using 'default' instead of 'defaultValue'
• Wrong parameter type name
• Incorrect case in parameter usage

5.

You want to create a Jenkins pipeline that asks for two parameters: a choice of ENV with options dev, qa, prod, and a boolean RUN_TESTS. The pipeline should print the selected environment and whether tests will run. Which snippet correctly defines these parameters and uses them in the Print Info stage?

hard

A. parameters {
choice(name: 'ENV', choices: ['dev', 'qa', 'prod'], description: 'Select environment')
booleanParam(name: 'RUN_TESTS', defaultValue: false, description: 'Run tests?')
}
stages {
stage('Print Info') {
steps {
echo "Environment: ${params.ENV}"
echo "Run tests: ${params.RUN_TESTS}"
}
}
}

B. parameters {
choice(name: 'ENV', choices: 'dev,qa,prod', description: 'Select environment')
boolean(name: 'RUN_TESTS', defaultValue: false, description: 'Run tests?')
}
stages {
stage('Print Info') {
steps {
echo "Environment: ${ENV}"
echo "Run tests: ${RUN_TESTS}"
}
}
}

C. parameters {
choice(name: 'ENV', choices: ['dev', 'qa', 'prod'], description: 'Select environment')
booleanParam(name: 'RUN_TESTS', default: false, description: 'Run tests?')
}
stages {
stage('Print Info') {
steps {
echo "Environment: ${params.ENV}"
echo "Run tests: ${params.RUN_TESTS}"
}
}
}

D. parameters {
choice(name: 'ENV', choices: 'dev,qa,prod', description: 'Select environment')
booleanParam(name: 'RUN_TESTS', defaultValue: false, description: 'Run tests?')
}
stages {
stage('Print Info') {
steps {
echo "Environment: ${params.ENV}"
echo "Run tests: ${params.RUN_TESTS}"
}
}
}

Solution

1. Step 1: Verify parameter definitions

   Choice parameter requires choices as a list, boolean parameter uses booleanParam with defaultValue.

2. Step 2: Check parameter usage in steps

   Parameters must be accessed as params.ENV and params.RUN_TESTS inside echo.

3. Final Answer:

   parameters { choice(name: 'ENV', choices: ['dev', 'qa', 'prod'], description: 'Select environment') booleanParam(name: 'RUN_TESTS', defaultValue: false, description: 'Run tests?') } stages { stage('Print Info') { steps { echo "Environment: ${params.ENV}" echo "Run tests: ${params.RUN_TESTS}" } } } -> Option A

4. Quick Check:

   Correct parameter syntax + params usage = parameters { choice(name: 'ENV', choices: ['dev', 'qa', 'prod'], description: 'Select environment') booleanParam(name: 'RUN_TESTS', defaultValue: false, description: 'Run tests?') } stages { stage('Print Info') { steps { echo "Environment: ${params.ENV}" echo "Run tests: ${params.RUN_TESTS}" } } } [OK]

Hint: Use list for choices and 'params.' prefix to access parameters [OK]

Common Mistakes:

• Passing choices as comma string instead of list
• Using 'default' instead of 'defaultValue' for booleanParam
• Accessing parameters without 'params.' prefix