| I believe this is one of the little bugs that are not really serious but still would make many people happy when fixed, because it is so annoying. I've found a generic workaround that doesn't use a shell step, so it's much more efficient. The trick is to temporarily clear the EnvVars for the duration of the "echo" call.  DISCLAIMER: This workaround disables the masking of secrets during the echo call, so use it at your own risk and especially don't use it within "withCredentials" scope!
If anyone has an idea to prevent this issue, please reply. We could propably call "getContext" to detect any "withCredentials" context and fallback to plain "echo" in this case. I could live with an occassional "Print Message" in "withCredentials" scopes. Unfortunately "getContext" prints a message on its own, so it's not very useful  . Sample code:
pipeline{
agent any
environment {
MY_ENV1 = 'foobarbaz'
}
parameters {
string(name: 'MY_PARAM', defaultValue: 'bazbarfoo')
}
stages {
stage('test') {
steps {
script {
env.MY_ENV2 = 'foobazbar'
withEnv(['MY_ENV3=bazfoobar']) {
// Any of the resolved variable values trigger the "Print message" of plain echo
def msg = "MY_ENV1=$MY_ENV1, MY_ENV2=$MY_ENV2, MY_ENV3=$MY_ENV3, MY_PARAM=$MY_PARAM"
echo "echo: $msg" // Displays "Print Message" as the step label
myecho "myecho: $msg" // Displays the message as the step label, as expected
}
}
}
}
}
}
// Workaround for "Print message" that is displayed by original echo step if the message
// contains a value of an environment variable or a pipeline parameter.
//
// WARNING: This disables masking of secrets in the output, so don't call it within witCredentials{} scope!
void myecho( String msg ) {
withContext( new MyEnvClearer() ) {
echo msg
}
}
// Clears all environment variables, to be used from withContext{}.
class MyEnvClearer extends org.jenkinsci.plugins.workflow.steps.EnvironmentExpander {
@NonCPS
void expand( hudson.EnvVars env ) throws IOException, InterruptedException {
env.clear()
}
}
|
