At the beginning of my pipeline a choice is made:
parameters {
choice(
name: 'jobRunMode',
choices: ['Create/Update','Delete'],
description: 'Job run mode')
}
However, when this build is triggered for the first time the user does not make a choice, thus this variable does not exist or is empty.
How do I check if this parameter exists or not?
A straightforward conditional for object value assignment would be: params.jobRunMode == null.
Instead of checking, just add Default Value to this param so it always exists xD.
Related
I have a jenkins pipeline which uses the defualt choice parameter.
parameters {
choice(choices: ['optA', 'optB'], description: 'Some options', name: 'CHOSEN')
}
Whenever it run the chosen options will always have a comma appended to it. Resulting in the step it's used in taking it as part of the argument.
someprogram.sh optA,
This breaks everything. How do I disable the comma? Also why is this default behavior?
I tried removing it with a combination of shell substition and jenkins groovy string manipulation.
I searched for the option 'omit field value' which 'fixes' this for a choices plugin (I am not using the reactive choices plugin but this is the only response I could find) When I try to find the 'omit field value' box in pipeline settings in parameters it doesn't exists.
Try replacing it like below.
sh "someprogram.sh ${params.CHOSEN}"
In Jenkins declarative pipeline we can define build parameters like
pipeline {
…
parameters {
string(name: 'PARAMETER', defaultValue: 'INITIAL_DEFAULT')
choice(name: 'CHOICE', choices: ['THIS', 'THAT'])
}
…
}
However the parameter definitions of the job are only updated when the job runs after the build parameters dialog was already shown. That is, when I change the INITIAL_DEFAULT to something else, the next build will still default to INITIAL_DEFAULT and only the one after that will use the new value.
The same problem is with the choices, and there it is even more serious, because string default can be overwritten easily when starting the build, but if the new option isn't there, it cannot be selected at all.
So is there a way to define functions or expressions that will be executed before the parameter dialog to calculate current values (from files, variable in global settings or any other suitable external configuration)?
I remember using some plugins for this in the past with free-style jobs, but searching the plugin repository I can't find any that would mention how to use it with pipelines.
I don't care too much that the same problem applies to adding and removing parameters, because that occurs rarely. But we have some parameters where the default changes often and we need the next nightly to pick up the updated value.
It turns out the extended-choice-parameter does work with pipeline, and the configurations can be generated by the directive generator. It looks something like
extendedChoice(
name: 'PARAMETER',
type: 'PT_TEXTBOX',
defaultPropertyFile: '/var/lib/jenkins/something.properties',
defaultPropertyKey: 'parameter'
)
(there are many more options available in the generator)
Groovy script to get global environment variables can be had from this other answer.
Sometimes, we want to create multiple jobs that use the same Jenkinsfile instead of a single one. This could happen for example because we want to maintain logs divided based on parameters, instead of having a single job on which look for the right log.
However, in this case, we can't use the parameter definition in the Jenkinsfile, because whatever default value we would define on the job instance would be overwritten by the following execution with whatever is defined in the Jenkinsfile (and this is also happening if we don't define a default value).
So, in this situation, the only way we figure out is to remove the parameter definition in the Jenkinsfile and define the parameters directly on the jobs, which is kind of not optimal.
I mean, I agree that this is the right behavior in most of the cases, as you don't want your parameter to be out of synch and not versioned, but is there a way to specify to Jenkins to skip the parameter reconfiguration or to override the default parameter written in the Jenkinsfile? Something that can be activated/deactivated job by job.
Had this problem myself, we solved it like this:
string(name: 'parameterName', defaultValue: params.parameterName ?:'your default value')
Now the default values defined through Jenkins job configuration will not be overridden.
Here i am using two choice parameter one is Branch and other is Component, Here i am able to run specific component but i need to run all the component at once?
1.Choices Parameter
Name: Branch
choices:trunk
branch/3.2.0
2.Choice Parameter:
Name: Component
Choices:loadbalance
alert
generic-report
backend-tool
You could declare 4 stages, each one with the second parameter already set (meaning not part of your parameters), and called using the parallel syntax
That way:
you don't have to deal with an "extended choice parameter"
you can differentiate each stage
you can run them in parallel
I am trying to create a Jenkins job that has dependent parameters.
Firstly I want to be able to choose a main parameter:
And then secondly to be able to choose from a set of options that are dependent parameters of the main parameter.
If I select a different main parameter:
I then want to have a different set of options as the dependencies to the second main parameter.
Please, can you help me with how I can achieve this?
I would suggest the Active Choices plugin (also known as "uno-choice"). (This question has references to both, though they're not the accepted answer.)
For your specific use case, you'll want to add two parameters to your job:
Active Choices Parameter
Name: MainOption
Script: Groovy Script
return ['A','B']
Active Choices Reactive Parameter
Name: DependentOption
Script: Groovy Script
def choices
switch(MainOption){
case 'A':
choices = ['Blue','Green','Yellow']
break
case 'B':
choices = ['Black','White','Grey']
break
default:
choices = ['N/A']
break
}
return choices
Fallback Script: Groovy Script
return ['Option error']
Referenced parameters:
MainOption
The "Referenced parameters" setting is the key - when that value is changed, the plugin will re-evaluate the Groovy script, giving you the dependent parameter effect.
For all of you who stumble upon the same kind of problem (like I did). There is a fairly new Jenkins plugin available that does exactly what is desired here: display a dependent set of drop-downs, updating dependent boxes when a main box changes selection.
For your job you just need to follow the following steps:
Install "Multiselect Parameter Plugin"
The "multiselect parameter plugin" can be installed from Jenkins plugin management, the documentation is available on its Jenkins Plugin page.
Add new parameter
Use "Multiselect Parameter" type
Set name to a sensible value
give a short description
configure like shown below:
H,Main option,Dependent option
V,SELECTED_MAIN,SELECTED_DEPENDENT
C,A,Blue
C,A,Green
C,A,Yellow
C,B,Black
C,B,White
C,B,Grey
Use selected values
When you run "build with parameters" in your job, the following boxes are displayed for selection:
In your build script you can simply use the configured environment variables SELECTED_MAIN and SELECTED_DEPENDENT, which contain the selected values from both select boxes.