$BUILD_STATUS token not recognized in emailext pipeline post action

[Sébastien Hinderer]

Dear all,

Given this Jenkinsfile:

pipeline {
agent { label 'foo' }
stages {
stage('Checking code style') {
steps {
sh '''
if [ ! -x tools/check-typo ] ; then
echo "tools/check-typo does not appear to be executable?"; >2;
exit 1;
fi
tools/check-typo
'''
}
}
}
post {
always {
emailext (
to: "ad...@domain.com",
subject: "Job ${env.JOB_NAME} $BUILD_STATUS " +
"(build #${env.BUILD_NUMBER})",
body: "Check console output at ${BUILD_URL}",
attachLog: true
)
}
}
}

The job runs just fine, the shell script is run as expected, but then
the emailext post actioon produces the following message:

[Pipeline] { (Declarative: Post Actions)
Error when executing always post condition:
groovy.lang.MissingPropertyException: No such property: BUILD_STATUS for class: groovy.lang.Binding
at groovy.lang.Binding.getVariable(Binding.java:63)
at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onGetProperty(SandboxInterceptor.java:270)
at org.kohsuke.groovy.sandbox.impl.Checker$7.call(Checker.java:353)
at org.kohsuke.groovy.sandbox.impl.Checker.checkedGetProperty(Checker.java:357)
at org.kohsuke.groovy.sandbox.impl.Checker.checkedGetProperty(Checker.java:333)
at org.kohsuke.groovy.sandbox.impl.Checker.checkedGetProperty(Checker.java:333)
at com.cloudbees.groovy.cps.sandbox.SandboxInvoker.getProperty(SandboxInvoker.java:29)
at com.cloudbees.groovy.cps.impl.PropertyAccessBlock.rawGet(PropertyAccessBlock.java:20)
at WorkflowScript.run(WorkflowScript:37)
at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.delegateAndExecute(ModelInterpreter.groovy:137)
at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.runPostConditions(ModelInterpreter.groovy:756)
at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.catchRequiredContextForNode(ModelInterpreter.groovy:395)
at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.catchRequiredContextForNode(ModelInterpreter.groovy:393)
at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.runPostConditions(ModelInterpreter.groovy:755)
at com.cloudbees.groovy.cps.CpsDefaultGroovyMethods.each(CpsDefaultGroovyMethods:2030)
at com.cloudbees.groovy.cps.CpsDefaultGroovyMethods.each(CpsDefaultGroovyMethods:2015)
at com.cloudbees.groovy.cps.CpsDefaultGroovyMethods.each(CpsDefaultGroovyMethods:2056)
at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.runPostConditions(ModelInterpreter.groovy:745)
at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.runPostConditions(ModelInterpreter.groovy)
at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.executePostBuild(ModelInterpreter.groovy:723)
at ___cps.transform___(Native Method)
at com.cloudbees.groovy.cps.impl.PropertyishBlock$ContinuationImpl.get(PropertyishBlock.java:74)
at com.cloudbees.groovy.cps.LValueBlock$GetAdapter.receive(LValueBlock.java:30)
at com.cloudbees.groovy.cps.impl.PropertyishBlock$ContinuationImpl.fixName(PropertyishBlock.java:66)
at sun.reflect.GeneratedMethodAccessor181.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72)
at com.cloudbees.groovy.cps.impl.ConstantBlock.eval(ConstantBlock.java:21)
at com.cloudbees.groovy.cps.Next.step(Next.java:83)
at com.cloudbees.groovy.cps.Continuable$1.call(Continuable.java:174)
at com.cloudbees.groovy.cps.Continuable$1.call(Continuable.java:163)
at org.codehaus.groovy.runtime.GroovyCategorySupport$ThreadCategoryInfo.use(GroovyCategorySupport.java:129)
at org.codehaus.groovy.runtime.GroovyCategorySupport.use(GroovyCategorySupport.java:268)
at com.cloudbees.groovy.cps.Continuable.run0(Continuable.java:163)
at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.access$001(SandboxContinuable.java:18)
at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.run0(SandboxContinuable.java:51)
at org.jenkinsci.plugins.workflow.cps.CpsThread.runNextChunk(CpsThread.java:185)
at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.run(CpsThreadGroup.java:400)
at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.access$400(CpsThreadGroup.java:96)
at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:312)
at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:276)
at org.jenkinsci.plugins.workflow.cps.CpsVmExecutorService$2.call(CpsVmExecutorService.java:67)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at hudson.remoting.SingleLaneExecutorService$1.run(SingleLaneExecutorService.java:131)
at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28)
at jenkins.security.ImpersonatingExecutorService$1.run(ImpersonatingExecutorService.java:59)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)

Both Jenkins and the relevant plugins are up-to-date.

Can anybody see whether I'm doing something wrong?

Many thanks in advance for any help,

Sébastien.

[Slide]

It's because you are using double quotes, which means Groovy (which pipeline is built on) will try and interpolate the variable. You would need to do something like this:

emailext (
        to: "ad...@domain.com",

        subject: 'Job $PROJECT_NAME $BUILD_STATUS (build #$BUILD_NUMBER)',
        body: 'Check console output at $BUILD_URL',
        attachLog: true
      )  

Note the single quotes instead of double quotes. I also replaced some of the tokens with ones provided by the token macro plugin, which is used by email-ext. If you wanted to use environment variables, you could use the ENV token, which would look like this: ${ENV, var="varname"}. The biggest thing though is the single quotes, if you have double quotes, as I mentioned previously, then Groovy will try and interpolate. You would need to escape the $ so that Groovy didn't try and interpolate.

Alex

--
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/20200806130637.GA68176%40om.localdomain.

--

Website: http://earl-of-code.com

[Sébastien Hinderer]

Dear Alex,

Many thanks for your very helpful response!

Slide (2020/08/06 07:01 -0700):

> It's because you are using double quotes, which means Groovy (which
> pipeline is built on) will try and interpolate the variable. You would need
> to do something like this:

[...]

I kind of thought I _needed_ double quotes for the expansion to work so
it's funny to discover that may very well be the cuase of the problem.

So am I understanding correctly that single quotes will (1) protect $foo
from being interpolate by Groovy but (2=) let token-macro expansion
continue to work? Is that right?

On IRC, I have also been advised not to use such variables but tather
those provided by Groovy directly and listed at

JENKINS_URL/job/JOB_NAME/pipeline-syntax/globals

So I tried to use currentResult (without any quotes around it) but that
didn't work either. Is it supposed to be a method and I am supposed to
use currentResult() ?

I also saw a mention of currentBuild.result but that I didn't try yet
and would be happy to get a hint on how to use that one and whether I
need to import something or so to get all this to work?


Many thanks again Alex and all,

Sébastien.

[Slide]

So am I understanding correctly that single quotes will (1) protect $foo
from being interpolate by Groovy but (2=) let token-macro expansion
continue to work? Is that right?

Yes, that is correct, email-ext (really token-macro) will parse the string and find the correct $ tokens to replace.

 

On IRC, I have also been advised not to use such variables but tather
those provided by Groovy directly and listed at

In my opinion, if you are using them in email-ext, you should use the tokens, otherwise some things will be available and other things won't and you will end up with a mashup of different variable types and tokens. This causes issues with quoting and so forth that can be hard to overcome. In other places in your pipeline, you should definitely use the normal groovy variables, but I would recommend using the available tokens in email setup.

Thanks,

Alex

--

Website: http://earl-of-code.com

[Sébastien Hinderer]

Many thanks Alex, what you write looks very sensible and makes a lot of
sense to me.

Best wishes,

Sébastien.