We had the same issue while using parallel builds & transitive upstreams. We reduced our build chain so that the downstream that should wait has exactly 3 upstream projects it should wait for.
- All are triggered at the same time
- One of those projects is a matrix build job (this is the longest running of those three)
- We're currently using Jenkins version 1.609.2
Now what happens is that the downstream waits until the matrix is almost finished. The downstream is started right before it is triggered again by the matrix parent.
See following example. This snippet is from the matrix job which triggers the downstream:
...
2016-01-24 22:19:35 Started calculate disk usage of build
2016-01-24 22:19:35 Finished Calculation of disk usage of build in 0 seconds
2016-01-24 22:20:05 Finished Calculation of disk usage of workspace in 29 second
2016-01-24 22:20:05 Warning: you have no plugins providing access control for builds, so falling back to legacy behavior of permitting any downstream builds to be triggered
2016-01-24 22:20:05 Triggering a new build of DOWNSTREAM
2016-01-24 22:20:05 Finished: SUCCESS
At this time the job called DOWNSTREAM was started once at 2016-01-24 22:19:40 and is triggered then again at 2016-01-24 22:20:05.
So even without considering transitive dependencies there's some issue with the "Block build when upstream is building"
Hope that it can be solved soon - or can we expected this already fixed in latest LTS?
To fix this properly without a giant lock, we need to be able to take a snapshot of the queue/executor status and base computation on that snapshot.
Then there's additional problem is that there's a small time window after a build is considered finished and before the build triggers kick in to schedule downstream jobs (this is needed so that downstream builds always see its upstream as completed.)