-
Bug
-
Resolution: Fixed
-
Major
I am attempting to calculate a value to be used in a few different places in my pipeline. The definition is in a method (in a global library, but I have identical behavior with an inline method).
environment {
MY_VAR = calculate()
}
In this scenario, MY_VAR is always null--even if the RHS is the GString {{ "${1+2}" }}! In fact, credentials() is the only non-compile-time-constant expression that I can get to evaluate to non-null.
I expected the values in the environment block to be evaluated on the master when the pipeline is started up and then injected appropriately.
- links to
[JENKINS-43681] Method calls in environment block are always null
Christopher Smith
created issue -
| Component/s | New: pipeline-model-definition-plugin [ 21706 ] | |
| Component/s | Original: pipeline [ 21692 ] |
| Assignee | New: Andrew Bayer [ abayer ] |
Christopher Smith
added a comment - Basically, the rules for the transform here are startlingly opaque, especially given the amount of treatment that the credentials() feature gets in the documentation. I can see a number of arbitrary breakpoints that could be defended as "this amount of foo is supported, but no more", but the limits and rationale need to be documented, and the proper handling of unsupported whatevers should be an error instead of a silent null. The lack of support for a constant-resulting GString is particularly unintuitive.
Christopher Smith
added a comment - Basically, the rules for the transform here are startlingly opaque, especially given the amount of treatment that the credentials() feature gets in the documentation. I can see a number of arbitrary breakpoints that could be defended as "this amount of foo is supported, but no more", but the limits and rationale need to be documented, and the proper handling of unsupported whatevers should be an error instead of a silent null. The lack of support for a constant-resulting GString is particularly unintuitive. You are not wrong. That said, I could have sworn I had tests for 1+2 sort of case...
Ah, yeah, we basically do - see https://github.com/jenkinsci/pipeline-model-definition-plugin/blob/master/pipeline-model-definition/src/test/resources/nonLiteralEnvironment.groovy again, specifically the ANOTHER_ENV declaration. What version are you on?
fwiw, adding a test for this specifically in https://github.com/jenkinsci/pipeline-model-definition-plugin/pull/154
| Remote Link | New: This issue links to "PR #154 (Web Link)" [ 16228 ] |
Christopher Smith
added a comment - Looks like 1.1.2 for everything, and I'm seeing an update to 1.1.3, and looking at the repo that seems that the feature expansion happened on the step between 1.1.2 and 1.1.3!
Christopher Smith
added a comment - Looks like 1.1.2 for everything, and I'm seeing an update to 1.1.3, and looking at the repo that seems that the feature expansion happened on the step between 1.1.2 and 1.1.3!
So this should work fine with a global library (not a library loaded via @Library or the libraries directive, though) - see https://github.com/jenkinsci/pipeline-model-definition-plugin/blob/master/pipeline-model-definition/src/test/resources/nonLiteralEnvironment.groovy for an example (returnAThing(...) is defined in the global library). This should get reworked for @Library and libraries to work, but an inline method I wouldn't expect to ever work.