-
Suggestion
-
Resolution: Fixed
-
None
As discussed in the forums (copied below for completeness); allow for option to have parent builds block children. This would allow children projects to use the most recent libraries from the parent, and prevent false positive builds where the parent is broken, or breaks compatibility. A side affect is that this also makes the build sequence more efficient by not building children that would obviously fail (when parent is failing).
Original response in forum:
Basil,
So what you want is the ability to "block" dependent builds when a parent build is running? e.g.
Build A has child builds B, C and D is a child of C.
If I check into all the sources simultaneously (though obviously A has to build first), then you'd want A to build, and B & C not to build until A is finished? And D not until C is finished? Are you doing this so since the child builds uses the libraries in the their builds?
> Basil: Yes, that is correct.
Also, if A build fails, B and C would not build. Would that be okay?
> Basil: Yes that is what's expected.
[BAM-734] "Block" dependent builds when a parent build is running
Jamie Stewart
added a comment - This may also help with a problem we are having, where you have project relationships
A -->B----->C
+---->D-->C
+---->E-->C
where a build of A triggers builds of its child projects (B, D, and E), which each trigger a build of C, so you end up with one change triggering 3 builds of C. This gets pretty annoying. One change of our core library currently results in about 10 instances of our distribution build firing off.
Jamie Stewart
added a comment - This may also help with a problem we are having, where you have project relationships
A -- >B ----->C
+---- >D -->C
+---- >E -->C
where a build of A triggers builds of its child projects (B, D, and E), which each trigger a build of C, so you end up with one change triggering 3 builds of C. This gets pretty annoying. One change of our core library currently results in about 10 instances of our distribution build firing off. 
Robert Watkins
added a comment - For a slight variation - consider that C may be a dependency of B as well.
Here's the graph
A -----> C -----> D
\ ^
\ |
---> B
Ideally, you would want C not to build until B is built, simply because building B will trigger a rebuild of C anyway.
Robert Watkins
added a comment - For a slight variation - consider that C may be a dependency of B as well.
Here's the graph
A -----> C -----> D
\ ^
\ |
---> B
Ideally, you would want C not to build until B is built, simply because building B will trigger a rebuild of C anyway. 
We're seeing this problem a lot - we have some build chains that are 5 projects long and it gets very annoying.
One possible way to implement this is through a form of priority / promotion.
i.e. when a build is added to a queue, check to see if any builds that depend on it are already on the queue but have not started yet.
If so, insert it before the topmost one (the one that'll run next).
e.g.
Assume there is a chain of 5 dependent builds A
> B -> C -> D -> E (> 'triggers') and some other unrelated builds (1, 2, 3, 4, etc).The build queue looks like this:
3 (Running), 7, 8
A developer checks code into builds B and D around the same time...
But build D happens to start first... queue is now
3 (Running), 7, 8, D
Now B will build... but instead of putting it on the end we notice D depends on it and promote it up the queue. i.e. the queue would then be:
3 (Running), 7, 8, B, D and not 3 (Running), 7, 8, D, B