<rakan>
Can anyone shed some light on how i can launch 2 or more builds concurrently and wait for both of them to finish as a group?
<rakan>
A combination of schedulers / builders and `Trigger` steps with `waitForFinish` don't seem to bring the desired result.
<rakan>
So let's say i have a (1) lints check step (2) build binary 1 (3) build binary 2 (4) test (5) code coverage... i want to be able to launch (2) and (3) concurrently but (4) should wait for both 2&3 to finish.
<glogan>
dependent scheduler, wait on the two builders
<bdbaddog>
rakan: what do you mean "doesn't seem to bring the desired result" ? Is it not waiting for finish?
<rakan>
bdbaddog assuming we have Scheduler 1,2 and 3 and each of them has a builder & a steps factory... a Trigger step in Scheduler 1 would invoke Trigger steps X,Y where X & Y's waitForFinish=False. This means that the builder from Scheduler 1 will not wait for neither of them to finish. Setting either one to True, would wait for 1... setting both of
<rakan>
them to True, would execute them serially. I hope i worded this correctly.
<rakan>
While the desired result would be to somehow have Scheduler 1 to trigger the two steps with waitForFinish=False to run them concurrently and still be able to not complete until they're both done.
<rakan>
glogan, as far as i can see... the DependentScheduler's upstream takes 1 instance of the "parent" scheduler
<glogan>
have the others grab a lock, and for the dependent one try to grab all the locks
<rakan>
That could work i guess... i'll give it a go
<bdbaddog>
ahh. IC. yeah there's not really simple way to implement a fork()/join() type process flow.
<bdbaddog>
oh yeah.locks…Been a. while.
<rakan>
glogan seems like the last Trigger acquires the lock first for some reason... i gotta figure out how to make it the other way around
<glogan>
You could spawn all the builds at once, with the locking scheme I described above. I *think* bb will be smart enough to allow the single lock builds to run first. Not sure tho
<glogan>
Although that might cause races, and end up firing the multi-lock build first. Hrm.
<glogan>
can you simplify the scheduler structure such that scheduler A fires off builds X,Y,Z and (dependent) scheduler B fires off the thing that has to run second?