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.
Related
I want to pass variable between release tasks. (from triggered build to script)
Files:
Script1: (saves a env variable)
Write-Output ("##vso[task.setvariable variable=MyVar;]$MyVarValue")
Script2: (prints the env variable value)
Write-host $env:MyVar
Script3: (same as Script2)
Write-host $env:MyVar
First approach: build
MyBuild:
Script1
Script2
This is working properly, the second script writes the value of $env:MyVar created in the first.
Second Approach: release
- MyRelease:
Script1
Script2
Also works properly.
My problem comes when my release changes to:
MyRelease:
Triggered_build (MyBuild)
Script3
In that last case, the Script3 is not printing the $env:MyVar, so I guess that release uses a different environment than the used for the triggered build?
Is there a way to do something like that?
No way to do that directly with TFS.
I have read about variable groups, but is not possible to set the variables dynamically in execution time with a script.
The only solution found is using the plugin Variable (de|re)Hydration Tasks
Solution from: Is possible to pass a variable from a Build to a Release in TFS 2017?
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.
How can I make generic parameters in jenkins that will be updated automatically for example I want to be able to create a parameter which hold today's date and it will be update automatically and not manually ?
thanks!
You might want to use EnvInject.
Setup your job and then add a build step "Inject envornment variables" from a file with an absolute path or the path relative to current job's workspace, which will contain something like:
DATE_VARIABLE="20150708"
OTHER_OPTIONAL_VARIABLE="value"
In previous execute shell step you may for example do:
echo "DATE_VARIABLE="`date +"%d%m%Y"` > env_inject.txt
After all that you don't need Parameters for a build, since you will have the needed parameter injected as an environment variable.
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 am using an Environment Variable so that that it can be modified and Recipient List will consume that environment variable.
So this value is passed as a build parameter:
Followed to that I am modifying it. Just as an example:
Now I am accessing this value in the recipient list:
Unfortunately Jenkins is not able to get this new value. It is using the old value. How this behavior can be fixed?
We need to use the EnvInject Plugin. One of the features is a build step that allows you to "inject" parameters into the build job from a settings file.
Create a property for the email list in the env.properties file:
echo "email_list=`dummy#test.com`"> env.properties
It will create the properties file in the job workspace directory.
env.properties
In Recipient list access this variable using the following:
"$email_list"