Jenkins jobs can be made way more flexible by letting you pass in parameters when you trigger a build. This means you can reuse the same job for different environments, branches, or configurations without having to duplicate it. Think of it like a function in programming where you pass arguments to change its behavior.
Let’s say you have a Jenkins job that deploys an application. Instead of having separate jobs for staging and production, you can have one job and pass in a TARGET_ENVIRONMENT parameter.
Here’s how it looks in action. First, you define the parameters in your Jenkins job configuration.
In your Jenkins job, go to "Configure" -> "General". Check the box for "This project is parameterized".
Then, click "Add Parameter". You’ll see a dropdown with different types. Let’s add a "String Parameter" named TARGET_ENVIRONMENT with a default value of staging.
Parameter Type: String Parameter
Name: TARGET_ENVIRONMENT
Default Value: staging
Description: The environment to deploy to (e.g., staging, production)
Now, when you go to build this job, you’ll see an input field for TARGET_ENVIRONMENT.
If you click "Build with Parameters", you’ll see:
Build with Parameters
TARGET_ENVIRONMENT: [ staging ]
You can change staging to production and then click "Build".
Inside your job’s build steps, you can access this parameter using the syntax ${PARAMETER_NAME}. For example, if you have a shell step:
echo "Deploying to ${TARGET_ENVIRONMENT}..."
# Your deployment script goes here, using TARGET_ENVIRONMENT
This shell step would output:
Deploying to production...
# Your deployment script goes here, using production
Other useful parameter types include:
- Boolean Parameter: A simple checkbox for true/false options. Great for toggles like "Run Tests?".
- Choice Parameter: A dropdown list of predefined options. Perfect for selecting which version of a database to use or which cloud region to deploy to.
- Credentials Parameter: Lets you select a Jenkins credential (username/password, SSH key) to use during the build. This is crucial for secure access to external systems.
- File Parameter: Allows you to upload a file as part of the build. Useful for configuration files or specific build artifacts.
- Git Parameter: Integrates with Git to allow selecting branches, tags, or commit hashes.
Let’s dive into the Choice Parameter for selecting a deployment region.
In your Jenkins job configuration, add another parameter:
Parameter Type: Choice Parameter
Name: DEPLOYMENT_REGION
Default Value: us-east-1
Choices:
us-east-1
us-west-2
eu-central-1
Now, your "Build with Parameters" screen will have two fields:
Build with Parameters
TARGET_ENVIRONMENT: [ staging ]
DEPLOYMENT_REGION: [ us-east-1 v ]
And in your build script, you can use both:
echo "Deploying to ${TARGET_ENVIRONMENT} in region ${DEPLOYMENT_REGION}..."
The mental model here is that each parameter acts like a variable that gets set before your build steps execute. Jenkins injects these values into the build environment, making them available as environment variables or through specific Jenkins pipeline syntax. You can even define parameters that depend on other parameters, creating dynamic workflows.
When you use parameters, you’re essentially creating a template for your builds. The job definition is the blueprint, and the parameters are the customizable fields that tailor the build to a specific instance. This dramatically reduces job sprawl and makes your CI/CD process more manageable and less error-prone. It encourages a "single source of truth" for build logic.
The real power comes when you combine parameters with pipeline-as-code (Jenkinsfile). In a Jenkinsfile, you define parameters at the top of your pipeline block.
pipeline {
agent any
parameters {
string(name: 'TARGET_ENVIRONMENT', defaultValue: 'staging', description: 'The environment to deploy to (e.g., staging, production)')
choice(name: 'DEPLOYMENT_REGION', choices: ['us-east-1', 'us-west-2', 'eu-central-1'], description: 'The cloud region for deployment')
}
stages {
stage('Deploy') {
steps {
script {
echo "Deploying to ${params.TARGET_ENVIRONMENT} in region ${params.DEPLOYMENT_REGION}..."
// Your deployment logic here
}
}
}
}
}
Here, params.TARGET_ENVIRONMENT and params.DEPLOYMENT_REGION are how you access the values passed in when you trigger the build. The parameters block defines what will appear in the "Build with Parameters" UI for this pipeline.
One thing that often trips people up is how parameters interact with SCM polling or webhook triggers. By default, if a parameterized job is triggered by a webhook or SCM poll, it will run with its default parameter values unless you’ve configured specific triggers to override them. This means an automatic build might deploy to staging if that’s your default, even if you intended it for a specific branch that should go to production. To handle this, you often need to use pipeline logic to inspect the SCM changes (like branch names) and dynamically set parameters within the Jenkinsfile itself, or use plugins that allow parameterized webhook payloads.
The next step after mastering basic parameters is often exploring how to dynamically generate parameter choices based on external data sources, like querying a list of available servers or fetching the latest Git tags.