If A is a job that builds something and B is a job that tests the something 
built by A, this might lead to serious problems.

Typically testing takes much longer than building, thus there will be more 
builds of A than builds of B. If every build of A kills a running build of B, 
you might not get a decent test run for your software until every developer 
goes home in the evening.

What if the tests complete in the evening and a test fails? And it fails 
because of a commit that was introduced in the morning? There are now a day's 
worth of new commits on top of it but the buggy commit went unnoticed because 
during the day not a single test run could be completed because every new build 
of A aborted the testrun of B. Wouldn't it have been better to catch the bug 
earlier?

If you're still convinced you want your Jenkins to work this way, ... I don't 
think there's any setting in Jenkins that makes it work like that. I also do 
not remember seeing a plugin for it. You might be able to use the Groovy plugin 
to run a Groovy script which examines the builds in progress and cancels a 
build of B if found.

-- Sami

dthomas kirjoitti 6.7.2012 kello 0.55:

> I have two projects A and B where B is a downstream project of A.
> When A is triggered while B is still building I would like to automatically 
> abort the current run of B since the result is no more useful and it will be 
> re-triggered soon anyway.
> Is there a way to achieve that in Jenkins?
> Thanks,
> - Dirk

Reply via email to