-
Improvement
-
Resolution: Fixed
-
Major
-
None
colored textOn the first build the config parameter doesn't exist but it'd be great if on this initial build Config parameter could be setup with the default value.
For example,
properties ([[$class: 'ParametersDefinitionProperty', parameterDefinitions: [[$class: 'StringParameterDefinition', defaultValue: 'Release', description: '', name: 'configParam']]]])
So
binding.hasVariable('configParameter') should return true, and should has the value Release
- is duplicated by
-
JENKINS-37330 Parametrised Jenkinsfile job always fails on first run
-
- Closed
-
- is related to
-
-
- Resolved
-
- relates to
-
-
- Open
-
-
-
- Resolved
-
- links to
[JENKINS-35698] Initial run of parameterized pipeline build should return properties default value
| Description |
Original:
On the first build the config parameter doesn't exist but it'd be great if on this initial build Config parameter could be setup with the default value. For example, properties ([[$class: 'ParametersDefinitionProperty', parameterDefinitions: [[$class: 'StringParameterDefinition', defaultValue: 'Release', description: '', name: 'configParam']]]]) So binding.hasVariable('configParameter') should return true, and should has the value 'Release' |
New:
On the first build the config parameter doesn't exist but it'd be great if on this initial build Config parameter could be setup with the default value. For example, {code} properties ([[$class: 'ParametersDefinitionProperty', parameterDefinitions: [[$class: 'StringParameterDefinition', defaultValue: 'Release', description: '', name: 'configParam']]]]) {code} So {{binding.hasVariable('configParameter')}} should return true, and should has the value {{Release}} |
| Labels | New: multibranch |
| Link |
New:
This issue is related to |
An implementation of JENKINS-27295 using a parameters virtual map could be designed to check for default values in ParametersDefinitionProperty even for keys not mentioned in ParametersAction, which would allow this to work on the first build:
properties([[$class: 'ParametersDefinitionProperty', parameterDefinitions: [[$class: 'StringParameterDefinition', name: 'mode', defaultValue: 'normal']]]]) assert parameters.mode == 'normal'
Matt Traynham
added a comment - Hey jglick, your workaround sort of fixes this for initial runs, but it fails when a Jenkinsfile "properties" has changed (maybe from a merge) and a subsequent run will use the old properties. This can cause jobs to fail or have undesired results. I imagine, based on the tutorials I've viewed and my own Jenkinsfile, that properties will likely always come at the beginning of the pipeline. So if the properties function could return a map, I think this would be much more straightforward, rather than injecting them into the binding (not a big Groovy user, but I think that's what it's doing).
Matt Traynham
added a comment - Hey jglick , your workaround sort of fixes this for initial runs, but it fails when a Jenkinsfile "properties" has changed (maybe from a merge) and a subsequent run will use the old properties. This can cause jobs to fail or have undesired results. I imagine, based on the tutorials I've viewed and my own Jenkinsfile, that properties will likely always come at the beginning of the pipeline. So if the properties function could return a map, I think this would be much more straightforward, rather than injecting them into the binding (not a big Groovy user, but I think that's what it's doing). | Workflow | Original: JNJira [ 172124 ] | New: JNJira + In-Review [ 184573 ] |
| Component/s | New: pipeline-general [ 21692 ] |
| Component/s | Original: workflow-plugin [ 18820 ] |
| Component/s | New: workflow-multibranch-plugin [ 21465 ] | |
| Component/s | Original: pipeline [ 21692 ] |
As shown here there is a workaround which probably just needs to make it into documentation. The requested behavior is not even theoretically possible.