I am trying to send an email in a post-build action, with the content set to some results I computed in a build action. I cannot seem to be able to pass variables from the shell code to any post-build actions.
I have tried with EnvInject, but haven't managed to make it work.
What am I missing?
As it always happens, I managed to find the solution right after I posted the question.
I managed to solve it by having something like this in the shell script bit:
EMAIL_CONTENT=$(cat <<EOF
Some content here.
Some content there.
EOF
)
EMAIL_RECIPIENTS="someone#example.com"
touch email_properties
echo "EMAIL_CONTENT=${EMAIL_CONTENT}" >> email_properties
echo "EMAIL_RECIPIENTS=${EMAIL_RECIPIENTS}" >> email_properties
And then, in the post-build action, I used Trigger parametrized build on other projects, with the Parameters from properties file option in order to trigger some other job whose only purpose is to email me those credentials. It's a bit of a work around, but it works.
Related
I want to pass a custom variable from Job A to Job B. I have tried achieving this using the "Parameterized Trigger" plugin but I didnt work for me.
I am doing it the following way:
On Job A:
execute shell --> export VAR=1
echo $VAR --> is returning 1
Trigger parameterized build on other projects:
PARAM=${VAR}
On JobB:
I have selected this project is parameterized and declared a variable as PARAM. But when I do execute shell --> echo ${PARAM} it returns be ${VAR} instead of 1.
Am I missing anything here ? Any pointers please ? Thanks in advance!!
That's due to the lifetime of VAR is limited within the Execute shell step. If you want variable cross step, even cross from Build to Post Action, you can output the variable to a file in Key = Value pattern, then read it back in Parameterized Trigger
I found a neat way to pass custom variables to downstream job here:
https://sathishpk.wordpress.com/2016/03/01/how-to-passget-parameters-from-shell-command-into-jenkins-other-places/
It worked for me!!
I would like to know if is possible to set a post build triggering the job with the last parameters. I've found this plugin https://wiki.jenkins-ci.org/display/JENKINS/Rebuild+Plugin but I can't have a properly way to call, this plugin is based on last job index.
It's a short question but I was not able to find a properly fix / workaround for that.
I think you must save this parameters in some file in workspace folder for example settings.xml or something similar, you can in easy way make command like this:
sh """echo '<name>$PARAMETER_VALUE</name>' >> ./settings.xml"""
When you would like to read this parameter you could use sed option or something else like:
sh """awk '{if($1 == "name") print $2}' ./settings.xml"""
When I run a manual build, I'd often like to mark it with documentation to show why I ran it. Is this feature available with a plugin?
thank you!
I would approach this by adding a build parameter as a string, as above, then use the Description Setter Plugin to set it from that parameter. We use something like this for the regex:
^\++ : BUILD DESCRIPTION : GERRIT_CHANGE_OWNER_EMAIL=([^#\s]*)\S*, BUILD_USER_EMAIL=([^#\s]*)\S*, GERRIT_BRANCH=(\S*), GIT_COMMIT=(\S{8}).*$
and this for the description:
\1\2, \4, \3
As a result we get:
jspain, 0ee3198b, master
or when it fails, we get:
Failed due to timeout.
wayvad, fc7bdf2a, master
this "Failed..." text comes from the Build Timeout Plugin
I am not aware of a plugin that can do this, and after a brief search I could not find one to do what you describe.
You can mimic this behavior by adding a string parameter in the job that takes a default value of automatically started when it's normally run, but that you can change to my reasons for this build when starting it manually.
You could then use a batch (or groovy or ) build step to print the contents of that parameter into the build log. If you do some sort of SCM checkout I'm not sure how close you can get it to print to the line that contains the username that started the job, however you can click on the view parameters button in the job build and see what was in the field quickly without having to parse the logs.
The downside of this is that parameter would have to be added to each job.
I have Job on Jenkins ver. 1.500 with build ID parameterized.
I want to use this parameterized value in the subject line of section "Post-build Actions".
If I try to access using $ID or ${ID} its printing it as plane string "$ID"[without value substitution]. I am aware of environmental variable $BUILD_NUMBER, which is giving the current job #number.
Can someone share, how to achieve this simple task of reading build number?
$PROJECT_NAME - Job # $ID built at $BUILD_ID - $BUILD_STATUS!
--Thanks,Prashant
It sounds like you are talking about Editable Email Notification post-build action. It has it's own way of referencing variables.
Variables that are available within the plugin, can be referenced directly as ${VARIABLE}, in both the body of the email and the subject line. For a list of available variables, click on the ? icon for on-page help.
However to access other environmental variables, including the parameters used by the build, you have to use the format ${ENV, var="VARIABLE"}, so in your case, it would be ${ENV, var="ID"}
I have Jenkins job that has execute shell part in which I have some variable
BUILD that is dynamically populated.
After build execution, I want to pass this variable to email-ext plugin Default Content to able to show it's value.
I've tried couple of ways without a success:
Passing this ${BUILD} value in Default Content is not recognized (Only Jenkins environment variables are visible in this context)
Defined new Jenkins global environment variable and tried to overwrite its initial value in shell context which apparently is not possible
Any idea on how to do this?
In my case, I'm not the administrator, then I can't install plugins. But can be done with a workaround.
In Content Token Reference help you can found an useful tool.
${PROPFILE,file="FILENAME",property="PROPERTYNAME"}
Expands to the value of a property in a property file. The filename is
relative to the build workspace root.
Then save values in a property file inside Build > Execute Shell:
rm -f ${WORKSPACE}/env.properties
touch ${WORKSPACE}/env.properties
store="/opt/current/store"
echo "store.folder=${store}" >> ${WORKSPACE}/env.properties
echo "${store}"
And read it from Post-build Actions > Editable Email Notification with:
${PROPFILE,file="env.properties",property="store.folder"}
Simple and easy:
In your "Execute Shell"
echo "test log" > /some/file/path/logFile.txt
Then in your "Editable Email Notification-Default Content"
${FILE,path="/some/file/path/logFile.txt"}
Build and you will receive a email with content "test log"
To see more email tokens, you can click the question mark beside "Content Token Reference" in "Editable Email Notification" section.
Use EnvInject Plugin to read the variable from a file, after you write that file in the "shell part".
In general, environment variables never go from child process back to parent process, this is basic feature of both Windows and Unix operating system families. Child always gets a copy of parent's environment, and if it modifies it, it modifies it's own copy (which is then copied to any child process if it launches any, etc). But to get changes back, some other method must be used, such as child writing desired changes to a file, which is then parsed by parent, which can then edit it's own environment based on it.
You can pass build parameters to email ext plugin by using:
${ENV,var="CAPITALIZED:VAR_NAME"}
In that way i see the variable value in the received mail.