A script generates a properties file to work-space in an Execute shell block in the Build section. This file is available at work-space after script execution and in case of Failed build (Conditional steps (multiple) block in the Build section) this properties file will be injected. My Jenkins job sends an E-mail (Editable Email Notification block) in case if Failed build and it should contains the variable from properties file but it doesn't see this variable. FYI: This block can use other environment variables.
I have cross-checked the properties file and it contains the required variable in every case.
Properties file in work-space:
Environment variable injection from properties file:
This Steps to to run if condition is met block contains more other actions and these work fine. It means the running can reach this block.
Editable Email Notification block in Post-build:
If I check the Environment Variables option in a build, I can see the variable:
But when I get the mail, it doesn't contain the variable:
Any idea how can I solve it or what should I change?
NOTE: The variable is unique and not really related to Gerrit so I cannot use another variable which comes form Gerrit. Just the name of var is a little tricky.
I have found the answer for my question. The Jenkins or the plugin has limitation. It cannot handle the Failure state. If the previous execute shell block is failed then the running won't reach the Conditional steps (multiple) block.
On the other hand, I have found a "workaround" for this problem.
1. step
You need to exit from the Execute shell block with a specific return code. Eg.: 111
2. step
You need to set the Exit code to set build unstable filed to your specific exit code. (You can find this field in advanced option of Execute shell block.) As you can see in the below picture.
3. step
Set the Conditional steps (multiple) block to handle the Unstable state. With this solution the running is able to run into Conditional steps (multiple) block.
4. step
Create an Execute shell block inside the Conditional steps (multiple) block after you prepare everything what you want in case of job failed. It means after this block your job status changes to Failed from Unstable.
Whit this solution you can handle the failed job and in the end you will get a real failed job (not unstable).
Not the most elegant solution but it works.
Related
In Jenkins, I want to automatically run a function on load of the shared library, which is loaded implicitally on a global level. This would allow me to enforce certain functions in every pipeline.
This means, a user would not have to define anything in the pipeline script itself to have it run.
What I tried:
//src/org/test/Always.groovy
#!/usr/bin/env groovy
package org.test
class Always implements Serializable {
Always() {
println "Always print me"
}
}
Always()
This does not appear to do anything, however. I would expect it to always instantiate the Always class and print "Always print me".
An global-pre-script-plugin exists that seems to fit your use case. It can execute a groovy script before each job / build starts. I am not sure if the script can load shared libraries and inject methods (maybe as Closure variable?) from it. This is something we would need to test :)
The plugin's last commit is from March 2020 though, so looks rather unmaintained to me.
This plugin makes it possible to execute a groovy script at the start
of every job
Features:
Applies to all jobs/builds run in the server
Executes a groovy script when a build starts Injects any number of variables in the build
Injects properties based on the content of another property
Executes a script when the build starts
Very light plugin
Failures in the script do not abort the build
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 have Upstream Job(MultiJob) which takes a String Parameter called freshORrerun, to take string value as "fresh" or "rerun" string value, which i need to pass on to downstream(standalone build) jobs to check the value is "fresh" or "rerun". Based on which, in child jobs's i will trigger complete tests run (pybot) or rerun (rebot) of failed tests.
here i have attached the screenshots how i have configured. When i print the passed string in child job it is empty.
Overall Job configuration.
Multi Job phase config and child Jobs
I have many no.of robot tests running them takes a lot of time. i need a way to run only failures of previous run, so that it gives me quick picture of how many got fixed. Could Some one please help me with this.
Click the 'Add parameters' button, select 'predefined parameters' and add: freshORrerun=${freshORrerun} to the list.
You can do it using one plugin called parameterized job trigger in which you will get options to pass parent job parameters to child job.
Note:- For this, you have to create parameters in child job also. These parameters will be overwritted.
plugin link
I'm using TFS2015 update 1. I want to pass information from one build step to the next, how is this possible?
That seems like a very simple task, but I can't figure out how that's suppose to work. Passing a variable to a build step is easy, but passing information from one step to the next seems to be impossible. I hope I'm wrong.
You can call the task.setvariable Logging Command, which sets a variable in the variable service of taskcontext. The first task can set a variable, and following tasks are able to use the variable. The variable is exposed to the following tasks as an environment variable.
Example:
##vso[task.setvariable variable=testvar;]testvalue
In Jenkins there is a possibility to create free project which can contain a script execution. The build fails (becomes red) when the return level of the script is not 0.
Is there a possibility to make it "yellow"?
(Yellow usually indicates successful build with failed tests)
The system runs on Linux.
Give the Log Parser Plugin a try. That should do the trick for you.
One slightly hacky way do do it, is to alter the job to publish test results and supply fake results.
I've got a job that is publishing the test results from a file called "results.xml". The last step in my build script checks the return value of the build, copies eihter "results-good.xml" or "results-unstable.xml" to "results.xml" and then returns a zero.
Thus if the script fails on one of the early steps, the build is red. But if the build succeeds its green or yellow based on the return code it would have retunred without this hack.