Pipeline: Accessing parameters in build broken

46 views
Skip to first unread message

Sverre Moe

unread,
Sep 26, 2016, 7:15:34 AM9/26/16
to Jenkins Users
I have previously accessed build parameters the following way:
def upstreamNoVerify = false
if (getBinding().hasVariable("PARAM")) {
    upstreamNoVerify
= Boolean.parseBoolean(PARAM)
}

This no longer works and I had to change it to:
final def upstreamNoVerify = Boolean.parseBoolean(PARAM)

I am beginning to get frustrated by this constant changes that breaks previous behaviour. I have read the changelog of plugins and Jenkins and could not find that this behaviour has been changed in any way. Jenkins could learn from Gradle and have a list of "Potential breaking changes" for every version.
Message has been deleted

Daniel Beck

unread,
Sep 26, 2016, 11:29:26 AM9/26/16
to jenkins...@googlegroups.com

> On 26.09.2016, at 13:15, Sverre Moe <sverr...@gmail.com> wrote:
>
> I am beginning to get frustrated by this constant changes that breaks previous behaviour. I have read the changelog of plugins and Jenkins and could not find that this behaviour has been changed in any way. Jenkins could learn from Gradle and have a list of "Potential breaking changes" for every version.

Other than this change (which mentions potential compatibility issues in the 2.3 changelog), what other compatibility issues did you experience to make this 'constant changes [breaking] behavior'?

Note that scripting this way you may well be circumventing @Restricted annotations and member visibility, and you should not expect them to remain the same between versions.

Sverre Moe

unread,
Sep 27, 2016, 2:57:15 AM9/27/16
to Jenkins Users, m...@beckweb.net
mandag 26. september 2016 17.29.26 UTC+2 skrev Daniel Beck følgende:

> On 26.09.2016, at 13:15, Sverre Moe <sverr...@gmail.com> wrote:
>
> I am beginning to get frustrated by this constant changes that breaks previous behaviour. I have read the changelog of plugins and Jenkins and could not find that this behaviour has been changed in any way. Jenkins could learn from Gradle and have a list of "Potential breaking changes" for every version.

Other than this change (which mentions potential compatibility issues in the 2.3 changelog), what other compatibility issues did you experience to make this 'constant changes [breaking] behavior'?
I see Jenkins 2.3 Changelog mention compatibility issues, but my script didn't stop working until a much later Jenkins version. Not sure which, but I think it was after 2.18->2.22. I patched my script September 13th, the day after updating Jenkins to 2.22. Prior to that I have been running with Jenkins 2.17.

Other compatibility issues I experienced after this update:
Access methods such as keySet() that threw java.io.NotSerializableException: java.util.LinkedHashMap$LinkedKeySet. It previously worked, but now I had to put it within a method using @NonCPS.

Because "list.each { value -> }" closure never worked in Groovy Pipeline, I have been using "for (def value : list)", but after an update that stopped working and I have to use a regular forEach "for (int i = 0; i<list.size();i++)".


Note that scripting this way you may well be circumventing @Restricted annotations and member visibility, and you should not expect them to remain the same between versions.

In what way? Am I accessing my defined boolean build parameter in a wrong way? 

Because of Jenkins 2.3 compatibility issues with SECURITY-170, the parameter is declared for the multibranch pipeline project in the pipeline script.
properties([[$class: 'ParametersDefinitionProperty', parameterDefinitions: [[$class: 'BooleanParameterDefinition', defaultValue: false, description: 'DESC', name: 'PARAM']]]])

Reply all
Reply to author
Forward
0 new messages