Parameterized Builds
Learn the concepts, syntax formats, dynamic inputs, and variable scoping workflows required to create flexible, re-usable pipelines that accept custom arguments at runtime.
What is a Parameterized Build?
A Parameterized Build allows you to pass custom values, flags, or configuration details directly into a Jenkins pipeline when executing a new build run. Instead of writing separate, hardcoded jobs for every distinct deployment environment or application branch, a single job can adapt dynamically using runtime inputs.
Common Parameter Variable Types
Jenkins natively supports several input parameter shapes inside the dashboard UI and declarative code blocks:
- String Parameters (`string`): Free-form text fields ideal for capturing dynamic variables such as git branch references, commit hashes, or custom release version tags.
- Choice Parameters (`choice`): Pre-configured drop-down list collections that restrict user selections to explicitly approved safety values (e.g., forcing a choice between `staging`, `testing`, or `production`).
- Boolean Parameters (`booleanParam`): Simple true/false checkbox toggles used to turn operational sub-actions on or off (e.g., checking a box to trigger an optional `RUN_SONAR_ANALYSIS` sequence).
Key Concepts
The `params` Object Scope
Understanding how Jenkins exposes chosen runtime parameter options inside a global environment variable namespace, accessed using standard dot-notation logic like `params.ENVIRONMENT_NAME`.
Default Value Cleanbacks
Learning to assign strict default parameter baselines so automated cron tasks or repository webhooks can still execute smoothly without requiring manual form interactions.
Practical Jenkins Example
The following declarative pipeline code shows how to declare multiple parameter input fields at the root layer and reference their active selections within pipeline execution stages:
pipeline {
agent any
// Declaring the parameterized input options
parameters {
choice(name: 'DEPLOY_ENV', choices: ['Development', 'Staging', 'Production'], description: 'Select the target hosting server environment.')
string(name: 'RELEASE_TAG', defaultValue: 'v1.0.0', description: 'Enter the application release version format tag.')
booleanParam(name: 'RUN_TESTS', defaultValue: true, description: 'Check to execute comprehensive automated regression tests.')
}
stages {
stage('Initialize Deployment Configuration') {
steps {
echo "Target deployment environment mapped: \${params.DEPLOY_ENV}"
echo "Target version release artifact tag selected: \${params.RELEASE_TAG}"
}
}
stage('Conditional Test Verification') {
when {
expression { return params.RUN_TESTS }
}
steps {
echo 'Executing unit and integration testing pipelines across workspace...'
}
}
stage('Deploy to Server Hub') {
steps {
echo "Pushing software binaries out to the verified \${params.DEPLOY_ENV} clusters..."
}
}
}
}Practice Exercise: Build an Environment Deployment Selector
Step-by-Step Task Sequence:
- Open the script block dashboard configuration for an active pipeline or initialize a new Pipeline item wrapper.
- Copy-paste the complete practical declarative sample code provided above inside your script editing area and hit **Save**.
- Note that the traditional **Build Now** sidebar link instantly changes to read **Build with Parameters** once the save finishes.
- Click **Build with Parameters**, modify the dropdown targets and checkbox toggle choices inside the generated UI menu, and click the blue **Build** button.
- Navigate into the current build iteration's **Console Output** screen to verify that the terminal outputs match your custom input settings exactly.
Summary
You have completed the Parameterized Builds lesson. Continue through the syllabus to see how to bundle and manage cross-pipeline execution tools securely inside the Global Tool Configuration menu.