Jenkins Course
Job Parameters
A pipeline that always does the same thing is useful. A pipeline that accepts inputs and adapts is powerful. Parameters are how you build the second kind — without writing a new pipeline for every variation.
This lesson covers
What parameters are → The five parameter types → The Build With Parameters UI → Reading parameters in pipeline steps → Default values → Validating parameter input
Without parameters, if you want to deploy to production instead of staging you need to edit the Jenkinsfile, commit, push, and trigger a build. That's slow, error-prone, and leaves a confusing Git history full of "change deploy target" commits.
With parameters, you click Build With Parameters, choose "production" from a dropdown, and hit Build. The pipeline reads your choice and deploys to the right place. No code changes. No Git commits. Just a clean, intentional input at trigger time.
The Analogy
A parameterised pipeline is like a restaurant with a menu instead of a fixed meal. The kitchen (pipeline) stays the same. The diner (the person triggering the build) chooses what they want from the menu (parameters). The same kitchen produces different results based on the order — without anyone reconfiguring the stoves.
What the Trigger Screen Looks Like
Once a pipeline has parameters defined, the Build Now button changes to Build With Parameters. Clicking it shows a form — one input per parameter. Here's what a typical parameterised deploy pipeline looks like to the person triggering it:
Target deployment environment
Version tag to deploy — e.g. 2.4.1
Run smoke tests after deploy
Optional notes about this release
The Five Parameter Types
string
A free-text field. The user types any value. Use for version numbers, branch names, ticket IDs, URLs — anything open-ended.
string(name: 'VERSION', defaultValue: '1.0.0')
choice
A dropdown menu with a fixed list of options. Use for environment targets, regions, or any constrained set of values. The first item in the list is the default.
choice(name: 'ENV', choices: ['staging', 'prod'])
booleanParam
A checkbox — true or false. Use for on/off flags like "run smoke tests", "notify Slack", or "skip database migration".
booleanParam(name: 'NOTIFY', defaultValue: true)
text
A multi-line text area. Use for release notes, SQL scripts, configuration blocks, or any input that spans multiple lines.
text(name: 'RELEASE_NOTES', defaultValue: '')
password
A masked text field — the value is hidden as the user types. Avoid this in favour of the Jenkins credential store for real secrets. Use it only for one-off, non-reusable values that don't need to be stored. The value is still passed as plain text in the build environment.
password(name: 'TEMP_KEY', defaultValue: '')
Building a Parameterised Deploy Pipeline
The scenario:
You're a senior DevOps engineer at a SaaS company. The release manager currently has to ask you to edit the Jenkinsfile every time they want to deploy a specific version to a specific environment. You're building a parameterised pipeline so they can do it themselves — choosing the environment, version, and whether to run smoke tests — without touching any code.
New terms in this code:
- parameters { } — the Declarative block where you define all pipeline inputs. Lives at the pipeline level, alongside
agentandstages. - params.PARAMETER_NAME — how you read a parameter value inside a stage or step.
paramsis a special Jenkins object that holds all parameter values for the current build. - when { expression { } } — a
whencondition that evaluates any Groovy expression. If the expression returns true, the stage runs. If false, it's skipped. This is how you make stages conditional on parameter values. - currentBuild.description — a field on the build object you can set from inside the pipeline. Whatever you write here appears as a subtitle under the build number in the Jenkins UI — useful for showing what was deployed.
pipeline {
agent { label 'linux' }
// Define all parameters here — Jenkins renders these as a form
// when the user clicks 'Build With Parameters'
parameters {
// Dropdown — restricts the user to valid environments only
choice(
name: 'DEPLOY_ENV',
choices: ['staging', 'qa', 'production'],
description: 'Target environment for this deployment'
)
// Free text — release manager types the version to deploy
string(
name: 'APP_VERSION',
defaultValue: '',
description: 'Version to deploy — e.g. 2.4.1. Leave blank to deploy latest.'
)
// Checkbox — on by default, release manager can uncheck to skip
booleanParam(
name: 'RUN_SMOKE_TESTS',
defaultValue: true,
description: 'Run smoke tests after deployment completes'
)
// Multi-line text — optional notes for the build log
text(
name: 'RELEASE_NOTES',
defaultValue: '',
description: 'Optional release notes — shown in the build description'
)
}
stages {
stage('Validate Input') {
steps {
script {
// Fail fast if a required parameter is missing
// Better to catch this here than halfway through a deploy
if (params.APP_VERSION == '') {
error('APP_VERSION parameter is required — please provide a version to deploy')
}
// Set a descriptive build name visible in the Jenkins UI
// Makes the build history page actually useful
currentBuild.description = "Deploy ${params.APP_VERSION} → ${params.DEPLOY_ENV}"
echo "Deploying version: ${params.APP_VERSION}"
echo "Target environment: ${params.DEPLOY_ENV}"
echo "Run smoke tests: ${params.RUN_SMOKE_TESTS}"
}
}
}
stage('Deploy') {
steps {
echo "Starting deployment of ${params.APP_VERSION} to ${params.DEPLOY_ENV}"
sh "./deploy.sh ${params.DEPLOY_ENV} ${params.APP_VERSION}"
}
}
// This stage only runs if the RUN_SMOKE_TESTS checkbox was ticked
// expression{} evaluates any Groovy boolean — here it reads the checkbox value
stage('Smoke Tests') {
when {
expression { return params.RUN_SMOKE_TESTS == true }
}
steps {
echo "Running smoke tests against ${params.DEPLOY_ENV}"
sh "./smoke-tests.sh ${params.DEPLOY_ENV}"
}
}
// This stage only runs if deploying to production
stage('Production Health Check') {
when {
expression { return params.DEPLOY_ENV == 'production' }
}
steps {
echo 'Running extended health checks for production deploy'
sh './health-check.sh production --extended'
sh "curl --fail https://api.acmecorp.com/health"
}
}
}
post {
success {
script {
// Build a useful summary message using parameter values
def notes = params.RELEASE_NOTES ? "\nRelease notes: ${params.RELEASE_NOTES}" : ''
echo "✅ Deployed ${params.APP_VERSION} to ${params.DEPLOY_ENV} successfully.${notes}"
}
}
failure {
echo "❌ Deployment of ${params.APP_VERSION} to ${params.DEPLOY_ENV} failed"
}
always {
cleanWs()
}
}
}
Where to practice: Add this Jenkinsfile to your repository. Create a Pipeline job in Jenkins pointing at it. On the first run, Jenkins reads the parameters { } block and registers the parameters — after the first build completes, "Build Now" changes to "Build With Parameters". Trigger a second build and you'll see the form. Full parameters reference at jenkins.io — Pipeline Parameters.
Started by user release-manager (Build With Parameters)
[Pipeline] Start of Pipeline
[Pipeline] node (agent-linux-01)
[Pipeline] { (Validate Input) }
[Pipeline] script
[Pipeline] echo
Deploying version: 2.4.1
[Pipeline] echo
Target environment: staging
[Pipeline] echo
Run smoke tests: true
[Pipeline] { (Deploy) }
[Pipeline] echo
Starting deployment of 2.4.1 to staging
[Pipeline] sh
+ ./deploy.sh staging 2.4.1
Deploying payments-service 2.4.1 to staging...
Deployment complete. Pods: 3/3 running.
[Pipeline] { (Smoke Tests) }
[Pipeline] sh
+ ./smoke-tests.sh staging
Running 12 smoke tests against staging...
All smoke tests passed.
[Pipeline] { (Production Health Check) }
Stage "Production Health Check" skipped due to when condition
[Pipeline] stage (post - success)
✅ Deployed 2.4.1 to staging successfully.
Release notes: Fix checkout timeout bug. Improve payment retry logic.
[Pipeline] cleanWs
[Pipeline] End of Pipeline
Finished: SUCCESS
What just happened?
Started by user release-manager (Build With Parameters)— Jenkins logs who triggered the build and how. The "(Build With Parameters)" tag confirms this was a manual parameterised trigger, not an automated SCM poll or schedule.- Validate Input ran successfully —
APP_VERSIONwas provided so theerror()call was skipped. The build description was set to "Deploy 2.4.1 → staging" — this now appears as a subtitle under build #88 in the Jenkins UI history. + ./deploy.sh staging 2.4.1— the two parameter values were passed directly to the shell script as arguments. The deploy script received the exact environment and version the release manager chose from the form.- Smoke Tests stage ran — because
RUN_SMOKE_TESTSwastrue, thewhen { expression { return params.RUN_SMOKE_TESTS == true } }condition evaluated to true and the stage executed. Stage "Production Health Check" skipped due to when condition—DEPLOY_ENVwas "staging", not "production", so this stage was automatically skipped. No production health check ran. Jenkins printed the skip reason clearly in the console — you can always see which stages were skipped and why.- Release notes appeared in the success message — the ternary expression
params.RELEASE_NOTES ? "..." : ''evaluated to true because the notes were non-empty, and they were included in the final log message. If the field had been left blank, the notes line would have been omitted.
The First-Run Quirk Every Engineer Hits
There is one behaviour that confuses almost everyone the first time they add parameters to a Jenkinsfile:
First build after adding parameters
Jenkins runs the pipeline without showing the parameter form. It uses the default values. The parameters are registered in Jenkins during this run — but the form doesn't appear until the second build.
Every build after that
The "Build Now" button becomes "Build With Parameters". Every subsequent trigger shows the form with your defined parameters and default values pre-filled.
Teacher's Note
Always make your default values safe — the first run uses them automatically. A default of production for your environment parameter is a bad day waiting to happen.
Practice Questions
1. What Jenkins object do you use to read a parameter value inside a pipeline stage — e.g. _____.APP_VERSION?
2. Which parameter type renders as a dropdown menu with a fixed list of options?
3. Which Jenkins build object field can you set from inside a pipeline to show a custom subtitle under the build number in the UI?
Quiz
1. What happens the first time you trigger a pipeline after adding a parameters { } block to the Jenkinsfile?
2. Which when condition correctly skips a stage if the boolean parameter RUN_SMOKE_TESTS is false?
3. When should you avoid using the password parameter type for real application secrets?
Up Next · Lesson 18
Credentials Management
Secrets, keys, tokens, and passwords — how Jenkins stores them securely and exactly how to inject them into pipelines without ever exposing them in a log.