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!

Upgraded to 1.1.3, and it looks like the value is being added to the environment. This works as expected:

environment {
  FIVE = "${2 + 3}"
  TWENTY_FIVE = "2${FIVE}"
}

However, method calls within the GString, like this:

environment {
  MY_VAR = "${formatDate()}-${BUILD_ID}"
}

where formatDate is a var in a local plugin, silently leaves MY_VAR undefined (causing various sorts of errors later on). Trying to use

MY_VAR = formatDate() + "-${BUILD_ID}"

resulted in "Environment variable values to be concatenated together must be single or double quoted". Using just

MY_VAR = formatDate()

works as expected, so it seems that the var bindings aren't getting applied to the GString evaluation context (and evaluation exceptions are getting swallowed silently). This is something I can work around a bit clumsily (export the string concat to a different method).

(As a side note, my apologies if I was rude in the initial exchange; I was at the end of a marathon trying to get the pipeline in place and had the social module turned off. The Declarative Pipeline is a major improvement in CI generally, and I'm glad to be adopting it.)

By the way, I don't know what the design decision here was, so I'm not sure whether/how to open a new issue on it, but the identifier MY_VAR in that case isn't defined in the steps themselves, so while I can say

echo "$MY_VAR"

I can't say

doStep MY_VAR

but have to use env.MY_VAR. It would be nice for the former to work, but I can imagine clashes that led to a decision not to, in which case it would be helpful to have a thorough explanation of why env is necessary in the docs.

Weeeeird - I honestly didn't think the changes in 1.1.3 would have made a difference with this, but hey, I'll take it. =)

Of those environment cases - yeaaaaah. There's a lot of hoop-jumping and evaluation at different points, so what's happening here is that the method is getting evaluated without the full context. I'll think on it and see if I can come up with a solution.

Re: the MY_VAR thing - what exactly is the error you're getting?

Code changed in jenkins
User: Andrew Bayer
Path:
pipeline-model-definition/src/test/java/org/jenkinsci/plugins/pipeline/modeldefinition/EnvironmentTest.java
pipeline-model-definition/src/test/resources/nonLiteralEnvironment.groovy
http://jenkins-ci.org/commit/pipeline-model-definition-plugin/e2001b6a7907bec8298faeafa16a88c7bcaa1ff4
Log:
JENKINS-43681 Just verify that a simple expression works as well

Code changed in jenkins
User: Andrew Bayer
Path:
pipeline-model-definition/src/test/java/org/jenkinsci/plugins/pipeline/modeldefinition/EnvironmentTest.java
pipeline-model-definition/src/test/resources/nonLiteralEnvironment.groovy
http://jenkins-ci.org/commit/pipeline-model-definition-plugin/595bf3379ed67a962902084149e1bf81cb437056
Log:
Merge pull request #154 from abayer/jenkins-43681-verify-test

JENKINS-43681 Just verify that a simple expression works as well

Compare: https://github.com/jenkinsci/pipeline-model-definition-plugin/compare/a185431a9658...595bf3379ed6

chrylis Ping - I'm trying to clean up tickets. Is this still a problem for you?

This definitely works with the JENKINS-42753 PR in any form I could come up with, even if it isn't working in Declarative 1.1.x. So worst case, it's fixed in the upcoming Declarative 1.2 release.

Bulk closing resolved issues.