Dynamic parameter values in Jenkins - Step-by-Step Execution

Process Flow - Dynamic parameter values

Start Job

↓

Display Parameters

↓

User selects parameter

↓

Parameter triggers dynamic update?

No→Use default/static value

Yes↓

Fetch new parameter values dynamically

↓

Update parameter options

↓

User confirms selections

↓

Run Job with selected parameters

The job starts by showing parameters. If a parameter triggers dynamic updates, new values are fetched and options updated before running the job.

Execution Sample

Jenkins

properties([
  parameters([
    choice(name: 'ENV', choices: ['dev', 'qa', 'prod'], description: 'Select environment'),
    choice(name: 'VERSION', choices: getVersions(params.ENV), description: 'Select version')
  ])
])

This Jenkins pipeline snippet shows how the 'VERSION' parameter choices depend dynamically on the selected 'ENV' parameter.

Process Table

Step	Action	Parameter	Value/Choices	Result
1	Start job	-	-	Parameters displayed with ENV choices ['dev', 'qa', 'prod'] and VERSION empty
2	User selects ENV	ENV	dev	Trigger dynamic update for VERSION
3	Fetch versions for ENV=dev	VERSION	['1.0', '1.1', '1.2']	VERSION choices updated
4	User selects VERSION	VERSION	1.1	Parameter selection complete
5	Run job with parameters	ENV, VERSION	dev, 1.1	Job executes with selected parameters
6	User changes ENV	ENV	prod	Trigger dynamic update for VERSION
7	Fetch versions for ENV=prod	VERSION	['2.0', '2.1']	VERSION choices updated
8	User selects VERSION	VERSION	2.0	Parameter selection complete
9	Run job with parameters	ENV, VERSION	prod, 2.0	Job executes with updated parameters

💡 Job runs after user selects parameters and dynamic values are updated accordingly.

Status Tracker

Variable	Start	After Step 2	After Step 3	After Step 6	After Step 7	Final
ENV	null	dev	dev	prod	prod	prod
VERSION choices	[]	[]	['1.0', '1.1', '1.2']	['1.0', '1.1', '1.2']	['2.0', '2.1']	['2.0', '2.1']
VERSION selected	null	null	1.1	1.1	1.1	2.0

Key Moments - 2 Insights

Why does the VERSION parameter choices change after selecting ENV?

Because VERSION depends on ENV, selecting ENV triggers fetching new VERSION choices dynamically as shown in steps 2 and 3 of the execution table.

What happens if the user changes ENV after selecting VERSION?

Changing ENV again triggers a dynamic update of VERSION choices (steps 6 and 7), so the previously selected VERSION may no longer be valid and must be reselected.

Visual Quiz - 3 Questions

Look at the execution table, what are the VERSION choices after the user selects ENV as 'dev'?

A ['1.0', '1.1', '1.2']

B ['2.0', '2.1']

C ['dev', 'qa', 'prod']

D []

💡 Hint

Check step 3 in the execution table where ENV is 'dev' and VERSION choices are updated.

At which step does the job run with ENV='prod' and VERSION='2.0'?

A Step 5

B Step 7

C Step 9

D Step 3

💡 Hint

Look for the step where parameters ENV='prod' and VERSION='2.0' are used to run the job.

If the user never changes ENV, what happens to VERSION choices after step 1?

A They default to ['2.0', '2.1']

B They remain empty

C They update dynamically

D They default to ['1.0', '1.1', '1.2']

💡 Hint

Refer to the variable_tracker and execution_table steps before ENV selection triggers updates.

Concept Snapshot

Dynamic Parameter Values in Jenkins:
- Parameters can depend on others.
- Selecting one parameter triggers update of dependent parameter choices.
- Use functions to fetch dynamic choices based on current selections.
- Job runs only after user confirms all parameters.
- Helps customize builds based on user input dynamically.

Full Transcript

This visual execution shows how Jenkins handles dynamic parameter values. The job starts by displaying parameters. When the user selects the ENV parameter, it triggers fetching new choices for the VERSION parameter dynamically. The user then selects a VERSION from updated options. The job runs with these selected parameters. If the user changes ENV again, VERSION choices update accordingly, requiring reselection. This process ensures parameters adapt dynamically based on user input before the job runs.

Practice

1. What is the main purpose of using dynamic parameter values in Jenkins jobs?

easy

A. To update input options based on other inputs or external data

B. To make Jenkins jobs run faster

C. To disable user inputs during job execution

D. To automatically restart failed jobs

Solution

1. Step 1: Understand dynamic parameters

   Dynamic parameters change their available options based on other inputs or external data sources.

2. Step 2: Identify the purpose

   This makes Jenkins jobs flexible and user-friendly by showing relevant choices dynamically.

3. Final Answer:

   To update input options based on other inputs or external data -> Option A

4. Quick Check:

   Dynamic parameters update options dynamically [OK]

Hint: Dynamic parameters change options based on other inputs [OK]

Common Mistakes:

• Thinking dynamic parameters speed up job execution
• Confusing dynamic parameters with job restart features
• Assuming dynamic parameters disable inputs

2. Which Jenkins plugin is commonly used to create dynamic parameter values based on a script?

easy

A. Pipeline Plugin

B. Git Plugin

C. Active Choices Plugin

D. Mailer Plugin

Solution

1. Step 1: Identify plugins for dynamic parameters

   The Active Choices Plugin allows parameters to be dynamically generated using Groovy scripts.

2. Step 2: Exclude unrelated plugins

   Git Plugin manages source control, Pipeline Plugin manages job pipelines, and Mailer Plugin sends emails, none create dynamic parameters.

3. Final Answer:

   Active Choices Plugin -> Option C

4. Quick Check:

   Active Choices Plugin enables dynamic parameters [OK]

Hint: Active Choices Plugin supports scripted dynamic parameters [OK]

Common Mistakes:

• Choosing Git Plugin for dynamic parameters
• Confusing Pipeline Plugin with parameter plugins
• Selecting Mailer Plugin unrelated to parameters

3. Given this Groovy script for an Active Choices parameter:

return ['dev', 'test', 'prod'].findAll { it.startsWith(params.ENV_PREFIX ?: '') }

What will be the parameter options if ENV_PREFIX is set to t?

medium

A. ['dev', 'test', 'prod']

B. ['test']

C. ['prod']

D. []

Solution

1. Step 1: Understand the script filtering

   The script returns list items starting with the value of ENV_PREFIX. Here, ENV_PREFIX is 't'.

2. Step 2: Filter the list

   From ['dev', 'test', 'prod'], only 'test' starts with 't'.

3. Final Answer:

   ['test'] -> Option B

4. Quick Check:

   Filter by prefix 't' gives ['test'] [OK]

Hint: Filter list by prefix to find matching options [OK]

Common Mistakes:

• Ignoring the prefix filter and returning full list
• Choosing empty list when prefix matches an item
• Selecting wrong matching item

4. You wrote this Active Choices script:

return ['one', 'two', 'three'].filter { it.contains(params.SEARCH) }

But Jenkins shows a syntax error. What is the problem?

medium

A. The parameter SEARCH must be declared as a string

B. The list should be a map, not a list

C. The script must use double quotes for strings

D. The method should be findAll instead of filter

Solution

1. Step 1: Check Groovy list filtering methods

   Groovy uses findAll to filter lists, not filter which causes syntax error.

2. Step 2: Confirm other parts are correct

   The list syntax and parameter usage are valid; string quotes can be single or double.

3. Final Answer:

   The method should be findAll instead of filter -> Option D

4. Quick Check:

   Use findAll for filtering lists in Groovy [OK]

Hint: Use findAll, not filter, to filter lists in Groovy [OK]

Common Mistakes:

• Using filter instead of findAll causes syntax errors
• Thinking list must be a map for filtering
• Believing quotes type causes syntax error

5. You want a Jenkins job parameter that lists all Git branches dynamically from a repository URL. Which approach correctly implements this dynamic parameter?

hard

A. Use Active Choices Plugin with a Groovy script that runs git ls-remote --heads <repo_url> and parses branch names

B. Use a String parameter and ask users to type branch names manually

C. Use a Boolean parameter to select if branches should be listed

D. Use a fixed Choice parameter with hardcoded branch names

Solution

1. Step 1: Identify dynamic branch listing method

   Active Choices Plugin with Groovy script can run shell commands to fetch live branch names from Git.

2. Step 2: Exclude static or unrelated options

   String parameter requires manual input, Boolean parameter is not for listing, fixed Choice is static and not dynamic.

3. Final Answer:

   Use Active Choices Plugin with a Groovy script that runs git ls-remote --heads <repo_url> and parses branch names -> Option A

4. Quick Check:

   Active Choices + git command fetches dynamic branches [OK]

Hint: Use Active Choices with git command to list branches dynamically [OK]

Common Mistakes:

• Using static parameters instead of dynamic scripts
• Choosing Boolean parameter for listing options
• Forgetting to parse git command output