-
Bug
-
Resolution: Not A Defect
-
Major
-
Jenkins:
- Core 2.76
- Ubuntu 15.04
- Pipeline plugins:
- pipeline-graph-analysis 1.5
- pipeline-rest-api 2.8 (2.9)
- pipeline-model-definition 1.2-beta-4
- pipeline-model-api 1.2-beta-4
- pipeline-stage-view 2.8 (2.9)
- blueocean-pipeline-editor 1.2.0
- pipeline-input-step 2.8
- blueocean-github-pipeline 1.2.0
- pipeline-stage-tags-metadata 1.2-beta-4
- pipeline-model-declarative-agent 1.1.1
- pipeline-model-extensions 1.2-beta-4
- blueocean-pipeline-api-impl 1.2.0
- blueocean-pipeline-scm-api 1.2.0
- pipeline-stage-step 2.2
- pipeline-build-step 2.5.1
- blueocean-git-pipeline 1.2.0
- blueocean-bitbucket-pipeline 1.2.0
- pipeline-milestone-step 1.3.1
- pipeline-github-lib 1.0
Agent:
- OS: Amazon Linux AMI VERSION="2017.03"
- Java: openjdk version "1.8.0_141"
Client:
- Fedora Workstation 26
- Google Chrome 60.0.3112.113 (Official Build) (64-bit)Jenkins: - Core 2.76 - Ubuntu 15.04 - Pipeline plugins: - pipeline-graph-analysis 1.5 - pipeline-rest-api 2.8 (2.9) - pipeline-model-definition 1.2-beta-4 - pipeline-model-api 1.2-beta-4 - pipeline-stage-view 2.8 (2.9) - blueocean-pipeline-editor 1.2.0 - pipeline-input-step 2.8 - blueocean-github-pipeline 1.2.0 - pipeline-stage-tags-metadata 1.2-beta-4 - pipeline-model-declarative-agent 1.1.1 - pipeline-model-extensions 1.2-beta-4 - blueocean-pipeline-api-impl 1.2.0 - blueocean-pipeline-scm-api 1.2.0 - pipeline-stage-step 2.2 - pipeline-build-step 2.5.1 - blueocean-git-pipeline 1.2.0 - blueocean-bitbucket-pipeline 1.2.0 - pipeline-milestone-step 1.3.1 - pipeline-github-lib 1.0 Agent: - OS: Amazon Linux AMI VERSION="2017.03" - Java: openjdk version "1.8.0_141" Client: - Fedora Workstation 26 - Google Chrome 60.0.3112.113 (Official Build) (64-bit)
-
-
Declarative - 1.2
Summary:
Given a Declarative Pipeline with a boolean parameter, which has a default setting of true, one might use this boolean to conditionally execute, or not execute, a particular stage. The syntax I've used to do this is similar to that shown in JENKINS-44298. It appears that changing this boolean at runtime, via the Jenkins UI, has no effect on whether or not the stage gets run.
Assumptions:
I'm working under the assumption that, a boolean parameter set up in the parameters
} condition written like this:
when {
expression {
return TRUE_OR_FALSE
}
}
is a valid way of deciding whether or not a stage gets run. Here, if TRUE_OR_FALSE is set to `true`, it'll run. If it's set to false, it won't. Similarly, if it were written like this:
when {
expression {
return !TRUE_OR_FALSE
}
}
The stage only gets run if TRUE_OR_FALSE is set to `false`.
I found this approach while working on issue JENKINS-44298.
Steps to recreate:
1. Create a new Pipeline job on your Jenkins, and use this as its code:
pipeline {
agent any
parameters {
// Default value here is true.
booleanParam(name: 'TRUE_OR_FALSE', defaultValue: true, description: 'This boolean defaults to true!')
}
stages {
stage('parallel-1') {
when {
expression {
// Given our default value is true, this should
// run if I don't change the parameter from its
// default value of true, to false.
return TRUE_OR_FALSE
}
}
steps {
echo "MUST BE TRUE"
} // end of steps
} // end of stage
} // end stages
}
2. Run this Pipeline by clicking "Build" on the left. The first time you do so, it'll fail anyway, because of a different bug that I'll look for / open separately. Nevermind that for now. 
3. Do a full page refresh in the UI, and the "Build" link has changed to "Build with parameters." Click this link, and leave the defaults. The boolean will be defaulted to True:
Go ahead and run it this way, and it'll run correctly.
4. Now, run it again, this time changing the parameter to false:
5. The stage will still run, as if you had not set the parameter to false.
[JENKINS-46552] Changing a boolean parameter at build time has no effect on conditional execution of a stage
Ok, yeah, it's referring to them as TRUE_OR_FALSE rather than params.TRUE_OR_FALSE that's creating the problem - if you use params.TRUE_OR_FALSE, it doesn't fail the first time and does the right thing. I can't remember off the top of my head how the params values end up made available as TRUE_OR_FALSE etc, but whatever's doing that is the problem. Digging into that now.
Got it - the build parameters get injected into the build environment over in https://github.com/jenkinsci/workflow-job-plugin/pull/24/files, and EnvVars is, behind the scenes, a String,String map - so any environment value will always be typed as a String, and return "false" is returning the String "false", and expression will treat any value other than null or false as if it were true. So...yeah. The right way to handle this is to always use params.TRUE_OR_FALSE.
So my guess here is that the parameter is actually getting represented as a String rather than a boolean here - which is not ideal. I'll need to test that further to be sure, but I'd guess that if you did return TRUE_OR_FALSE == "true", it'd work. I'll determine if this is a bug in Declarative's handling or deeper in the stack.