[workflow-plugin] bug? using build parameters to skip builds steps

[sebastien....@gmail.com]

Hello,

I would like to add a build parameter "clean" which is true by default, but, when false, make the job skip the clean step.

Here is my script

echo "clean: ${clean}"
node("qisrc") {
  echo "clean: ${clean}"
  if (clean) {
    sh "echo clean"
  }
  sh "echo build"
}

Here is what happens when I build with clean parameter unchecked:

Running: Print Message
clean: false
Running: Allocate node : Start
Running on qisrc in /home/jenkins/jenkins/workspace/workflow
Running: Allocate node : Body : Start
Running: Print Message
clean: false
Running: Shell Script
[workflow] Running shell script
+ echo clean
clean
Running: Shell Script
[workflow] Running shell script
+ echo build
build
Running: Allocate node : Body : End
Running: Allocate node : End
Running: End of Workflow
Finished: SUCCESS

As you can see, the variable "clean" is false as expected, but the sh "echo clean" command is ran anyway.

Is it expected?

[Vincent Latombe]

Remember that in groovy

if ("false") {
 println("Hello world")
}

will indeed echo Hello world

Use

if (clean.toBoolean()) {

  sh "echo clean"

}

should work better for you.

Vincent

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/48dbdae4-beae-4004-a44a-5f5ffcd30eeb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[sebastien....@gmail.com]

On Thursday, February 19, 2015 at 11:13:08 AM UTC+1, Vincent Latombe wrote:

Remember that in groovy

if ("false") {
 println("Hello world")
}

I didn't realize that my "Boolean Parameter" was actually a variable of type String. That now makes perfect sense, thank you!

[Jos Backus]

But isn't that a bug? Why doesn't the surrounding code cast the parameter to a Boolean value, as certainly I would expect?

[Vincent Latombe]

No, it is how the groovy truth is defined. See http://docs.codehaus.org/display/GROOVY/Groovy+Truth

Non-empty strings are coerced to true, even if the value is "false".

Vincent

2015-02-20 6:11 GMT+01:00 Jos Backus <j...@catnook.com>:

But isn't that a bug? Why doesn't the surrounding code cast the parameter to a Boolean value, as certainly I would expect?

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/a5c46e5e-6dec-4736-ba5d-4653f2da7695%40googlegroups.com.

[sebastien....@gmail.com]

On Friday, February 20, 2015 at 8:11:38 AM UTC+1, Vincent Latombe wrote:

No, it is how the groovy truth is defined. See http://docs.codehaus.org/display/GROOVY/Groovy+Truth

Non-empty strings are coerced to true, even if the value is "false".

Yes, I agree  with that, there is no Groovy bug here.

2015-02-20 6:11 GMT+01:00 Jos Backus <j...@catnook.com>:

But isn't that a bug? Why doesn't the surrounding code cast the parameter to a Boolean value, as certainly I would expect?

I'm tempted to agree with Jos too, why is the variable created by a "Boolean Build Parameter" (from the top of the job configuration page) not a boolean variable in the first place?

I guess is has something to do with compatibility with non-workflow jobs, which access the parameter as an environment variable (instead of a groovy variable), but you got the point.

Sébastien

[Jesse Glick]

On Friday, February 20, 2015 at 2:37:21 AM UTC-5, sebastien....@gmail.com wrote:

why is the variable created by a "Boolean Build Parameter" (from the top of the job configuration page) not a boolean variable in the first place?

I guess is has something to do with compatibility with non-workflow jobs, which access the parameter as an environment variable (instead of a groovy variable)

You guessed right.

For certain kinds of parameters, there may be a more natural Groovy object that the value could be set to. The Jenkins API for ParameterValue does now (1.568+) define getValue. Changing the way parameters are bound in workflows now would be a compatibility break, unless you opted in to the change in behavior somehow, so TBD. File an RFE for it if you think it is important.