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