i have configured a Jenkins pipeline job as follows
and env.WORKSPACE works fine
steps {
script
{
echo "${env.WORKSPACE}"
}
}
during build ouput is /home/mach1/workspace
but when i added some lines in post build stage in jenkins pipeline job.
it is returning the following error ${FILE,path="echo "${env.WORKSPACE}"/dir1/file2.html"}
script
{
echo "${env.WORKSPACE}"
}
}
post{
success{
script{
body:'${FILE,path="${env.WORKSPACE}/dir1/file2.html"}'
}
}
}
may i know where its getting wrong, or how do i correct so that in post step it takes /home/mach1/workspace/dir1/file2.html
A shell environment variable is referenced as a key within the env Map within Jenkins Pipeline Groovy, and as a string within the shell step method. In your original example, you referenced the variable as a Groovy variable, and interpolated it within the pipeline with the correct " syntax. However, in your second example, you are still referencing the variable as a Groovy variable, but attempting to interpolate it within the executed shell command from the step method. This will not work, as you will pass a literal string of the env Map variable.
You can fix this either by referencing the environment variable as a shell environment variable by removing the env Map key:
body:'${FILE,path="${WORKSPACE}/dir1/file2.html"}'
or by interpolating the Groovy variable within the pipeline:
body:"\${FILE,path=\"${env.WORKSPACE}/dir1/file2.html\"}"
where characters are properly escaped to denote a shell variable FILE as opposed to a Groovy variable, and for the embedded ".
The first correction is, of course, easier to read, and probably what you will prefer.
Related
Just for my curiosity I have a question related to the groovy behavior in the shell step.
I have defined an environment variable REGISTRY_AT in Jenkins and a build parameter VERSION. I know that for Groovy to do substitution on variables they need to be enclosed in double quotes and from experience the following example works.
Example:
dir('metrics/metrics-client'){
sh '''
....
docker build -t "${REGISTRY_AT}"/metrics-client:"${VERSION}" .
'''
}
Question: Why does Groovy engine interpolate the variables if they are inside a triple quoted string which will be passed to the shell step (sh -c " ") as an argument?
Maybe I'm looking at it the wrong way but from the groovy documentation, every string that is defined with single quotes/triple quotes shouldn't support interpolation/substitution
I've searched a lot of answers and documentation but cannot understand fully how the groovy engine works in the case of Jenkinsfiles and it's been bugging me for a while since the inner workings of Jenkins + Groovy + Shell related to variable interpolation (environment, parameters, local defined variables, etc) always cause some confusion, even for those that have worked with the pipelines.
In this case, there is no string interpolation. Because you defined the variables REGISTRY_AT and VERSION as environment variables, they exist in the shell script as environment variables as well.
So there is no string interpolation at the point of the triple-single quotes, but there is string interpolation in the shell script itself.
I am trying to use Jenkins environmental variable with groovy scripts and assign them to environment variable so I can use those variable through out each Jenkins steps. But I cannot take out Groovy map objects. Is there anything I am doing wrong?
this is simple. In groovy script I have added two keys as "repo" and "version". Environment variables are created from that name and in a shell, I can get those simply by calling their keys.
echo $repo
echo $version
I need to get GitVersion.exe variables in my Jenkins pipeline.
The GitVersion documentation gives a hint on how to do that. Essentially call gitversion /output buildserver.
This call does add the variables to the current step and they are lost once the step completes. I can show this call executes when combining a set command in the same bat execution. The second set shows the variables are gone from the environment.
bat 'nuget install GitVersion.CommandLine -OutputDirectory c:/packages -Version 3.6.5'
bat 'c:/packages/GitVersion.CommandLine.3.6.5/tools/GitVersion.exe /output buildserver && set'
bat 'set'
The documentation of GitVersion is aware of that and suggests to use EnvInject.
Installing the plugin and executing the same pipeline did not change the result. I read that the Plugin is not made for pipelines so that may have something to do with it.
Pipelines support a syntax for environment.
Following that syntax I can set static variables at the top of my pipeline like this:
environment {
ASuperVariable = 'MySuperVariable'
}
What I need is combining those calls so that I can add run time variables to the Jenkinsfile pupeline.
environment {
bat 'gitversion /output buildserver'
}
Now obviously the above call is not even syntax correct. Is there a way to mark a section so that the contained environment changes are available for other steps?
EDIT:
This is still unsolved. At the moment I need to create a batch script and pass the tool into it as an argument. Inside the batch I can call the tool to add to the environment of the batch script and use that wile the batch is running. A Multi line batch in the Jenkins file could be a solution if the process remains the same over all the multiple lines.
Not sure whether you would be able to use scripted pipeline or at least a script block inside declarative. It'd be quite easy doing so:
withEnv(['ASuperVariable=MySuperVariable']) {
echo env.ASuperVariable
}
Or when calling a windows cmd script:
node('win') {
withEnv(['ASuperVariable=MySuperVariable']) {
bat 'echo %ASuperVariable%'
}
}
Is there any environment variable available for getting the Jenkins Pipeline Title?
I know we can use $JOB_NAME to get title for a freestyle job,
but is there anything that can be used for getting Pipeline name?
You can access the same environment variables from groovy using the same names (e.g. JOB_NAME or env.JOB_NAME).
From the documentation:
Environment variables are accessible from Groovy code as env.VARNAME or simply as VARNAME. You can write to such properties as well (only using the env. prefix):
env.MYTOOL_VERSION = '1.33'
node {
sh '/usr/local/mytool-$MYTOOL_VERSION/bin/start'
}
These definitions will also be available via the REST API during the build or after its completion, and from upstream Pipeline builds using the build step.
For the rest of the documentation, click the "Pipeline Syntax" link from any Pipeline job
To avoid problems of side effects after changing env, especially using multiple nodes, it is better to set a temporary context.
One safe way to alter the environment is:
withEnv(['MYTOOL_HOME=/usr/local/mytool']) {
sh '$MYTOOL_HOME/bin/start'
}
This approach does not poison the env after the command execution.
I trigger a shell script from Jenkins, This scripts get date and export it as a environment(Linux) variable $DATE. I need to use this $DATE inside same Jenkins job. I made job as parameter build. Created a string parameter as DATE value as DATE=$DATE. But it is not working.
Please suggest !!
You mention that you are exporting a DATE environment variable in an shell script, which is presumably being started via an "Execute shell" step.
The problem is, once the shell step has completed, that environment is gone — the variables will not be carried over to subsequent build steps.
So when you later try to use the $DATE value — whether in another build step, or as a parameter to another job — that particular environment variable will no longer exist.
What you can do instead is use the EnvInject plugin to export environment variables during a build. Variables set up using this plugin will be available to all subsequent build steps.
For example, you could write the DATE to a properties field in one build step:
echo DATE=$(date +%Y-%m-%d) > env.properties
Then you can add an "Inject environment variables for your job" build step, and enter env.properties in the "Environment Properties File Path" field.
That way, the DATE variable (and anything else in that properties file) will be exported and will be visible to the rest of the build steps.
You could use an assignment statement and sh's returnStdout to get the value in Jenkins without having to write to a properties file.
foo = sh(
returnStdout: true,
script: 'date'
)
Then later on in the Jenkinsfile you can use $foo like any other variable.
EDIT: This is for a pipeline job, not a freestyle job.
I had the same issue.
The solution that worked for me was:
env.ABC=bat(returnStdout: true,
script: ''' #echo off echo abc ''').trim()
The .trim() and #echo off is important if you want to reuse the variable in another batch script.