Details
-
New Feature
-
Status: Resolved (View Workflow)
-
Major
-
Resolution: Fixed
-
None
-
Dependant matrix builds across Linux and Solaris
Description
When a downstream build is in progress, Hudson should prevent the upstream builds from occurring until the downstream build is complete.
For example:
CompA->CompB->CompC->CompD
If component C is building Hudson should block builds on A and B, until C has finished.
It should then rebuild A, B and C before allowing D to proceed.
As the current system stands, if a user presses "build now" on component A when component C is building, A builds immediately. This can be worked around in part by using the locks & latches plugin, but this has the side affect of disabling parallel Matrix builds which massively increases the build time (see JENKINS-2725). Further, it should NOT be necessary to use ANY plugins to provide this fundamental behaviour.
Here's another use case I have:
Large build with a large suite of tests (unit + 1.5hrs worth of selenium browser tests).
Job A:
Builds the app, starts it up
Job B:
Matrix job using a custom workspace that points to Job A's workspace
4 elements in 1 Axis: 4 test suites that are run simultaneously
We cant have Job A run while Job B is running because it'll wipe the workspace out. Job A has an SCM poll trigger which on a busy day will already have another run queued while B is still running. Rather than space SCM polls several hours apart, we'd rather the build for Job A be blocked by its downstream job.
Locks and latches doesn't work because each instance of Job B (it's a matrix job, remember) tries to grab a lock, preventing the instances from executing concurrently.
(Also note that we've found custom workspace to be the best option because the Copy Workspace has some crappy limitations (doesnt copy permissions, doesnt copy empty directories) and tarring/untarring a 1gb build is a waste of time and space)