Reputation: 3943
I have a full set of unit tests I'd like to run daily overnight in Jenkins, but only if my application has built correctly in another job. I DON'T want the unit tests to trigger throughout the day as commits are added to the application.
How do I configure this? To restate: there are two Jenkins jobs:
A and B:
A runs each checkin, unless B is running, in which case it waits for B.
B runs at midnight, IFF A is in a good state. If A is running, B waits for A.
I already have A set up as "A runs each checkin."
Upvotes: 3
Views: 11819
Reputation: 4368
My answer is a bit late to the party here (sorry :-7) but a useful question and not answered properly(sorry guys - not your fault - it took me/us a few years to find out the best different ways of doing this (originally I had some post-build groovy and other scripts doing funky things like triggering other jobs)). Actually jenkins has quite a flexible choice of methods for jobs that need to interact with one another.
There is a built in "Post-build Action: build other projects" and there are a couple of plugins which can be used. The "Post-build Action: build other projects" is probably most suitable. And the "Lockable Resources Plug-in" can be used to make the jobs mutually exclusive.
* SIMPLEST ANSWER: *
Install Lockable Resource plugin and add a lockable resource "build_or_test" and configure jobs A and B to lock on that resource.
Configure the build job A, Add Post-build Action: Build other projects Build job B if job A is Stable.
* LIST of useful built-ins and plugins: *
It is also useful to use FSTrigger plugin, build jobs or other jobs may generate logs or image files or test reports. Jobs can be triggered to run when these files or directories appear or are updated. Jobs in remote jenkins or external to jenkins can be used to trigger jobs using this method.
Built in Post-build Action: Build other projects
* Trigger only if build is stable
* Trigger even if the build is unstable
* Trigger even if the build fails
BuildResultTrigger Plug-in - This plugin makes it possible to monitor the build results of other jobs. Similar to "Post-build Action: build other projects" only at top of job config as a trigger with cron schedule.
Filesystem Trigger Plug-in - The plug-in makes it possible to monitor changes of a file or a set of files in a folder.
Parameterized Trigger Plug-in (which adds Post-build Action: Trigger parameterized build on other projects) Similar to "Post-build Action: build other projects but convenient to pass build information e.g. in parameters.ini style file or boolean or other params from one job to another.
Lockable Resources Plug-in This plugin allows to define external resources (such as printers, phones, computers) that can be locked by builds. If a build requires an external resource which is already locked, it will wait for the resource to be free.
Upvotes: 2
Reputation: 524
I assume you are using Jenkins pipeline. There might be many ways but I would address this by adding a new stage in JOB B that check the status of JOB A and a utility function to check status.
stage('check Job A status'){
// If A is running, B waits for A.
if(checkStatus() == "RUNNING" ){
timeout(time: 60, unit: 'MINUTES') {
waitUntil {
def status = checkStatus()
return (status == "SUCCESS" || status == "FAILURE" || status == "UNSTABLE" || status == "ABORTED")
}
}
}
// Proceed with B, only when A is in a good state
if( checkStatus() != "SUCCESS" ){
error('Stopping Job B becuase job A is not successful.')
}
}
def checkStatus() {
def statusUrl = httpRequest "https://jenkins.example.com/job/${job-A-Name}/lastBuild/api/json"
def statusJson = new JsonSlurper().parseText(statusUrl.getContent())
return statusJson['result']
}
Upvotes: 9
Reputation: 1401
You can publish a "state" on completion of Job A. Say a property file in your source code repo, or even in DB. This value can be boolean. If Job A is running, value will be false till Job A build successfully. Now, when Job B gets triggered, first check if the above value is true or not.
It seems there is no plugin to support this. Most of the plugins will trigger the Job B as soon as Job A is done (ie it will monitor status of Job A).
Upvotes: 1
Reputation: 5321
Off the top of my head, I can't think of a way to do exactly what you want. But that might be because it is probably not the best way to handle it.
In job A, you should probably just not deploy/deliver the artifacts to the place where B will look unless the build is successful. Then B will always run against a successful build from A.
But without understanding your entire setup or environment, I can't really comment on what is "right". But maybe you need to rethink the problem?
Upvotes: 1