-
New Feature
-
Resolution: Unresolved
-
Major
-
None
Jenkins support "advanced" job options to block a build when either an upstream or downstream project is building. This feature is great for preventing dependent jobs from running concurrently, however it would be better if this option also watched the state of these dependent jobs as well, so as to prevent downstream jobs from running when their upstream dependencies are broken.
Use Case:
Suppose you have two jobs: JobA and JobB, where JobB depends on the outputs generated by JobA and thus is set to trigger after JobA completes successfully. You can configure both jobs, using the advanced job options just mentioned, such that the two jobs can never run concurrently, however you can still run JobB even if JobA is broken. This leads to erroneous results, where build failures in JobB are not related to changes made to the artifacts managed by JobB, but are rather a side effect of the dependent JobA being broken.
This problem gets further exacerbated when each of your jobs are configured with SCM triggers and you have a large number of interdependent jobs. If someone commits a change to the source managed by Job1 and it breaks, then someone else commits a change to the source managed by downstream Job10, that build will fail regardless of whether the change just committed is in error or not. The farther the downstream job is from the upstream job the more difficult it becomes to manage the resulting failures. Suppose Job1 stays broken for a few hours, and in the meantime developers commit changes to downstream jobs 3, 5, 7 and 10. Each of these builds in turn will fail because due to the upstream failure, however one can not tell whether these failures are related to the job1 issues or if they are caused by subsequent commits.
- is related to
-
JENKINS-19728 Much needed dependency management between jobs
- Open