-
New Feature
-
Resolution: Unresolved
-
Major
-
None
Add option to fail the flow build when a parallel job fails.
Build flow config on orcastrator job:
build("Build and publish artifacts") parallel ( { build("Slow tests 1") }, { build("Slow tests 2") }, { build("Fast tests 1") }, { build("Fast tests 2") } )
Lets say "Fast tests 1" fails on formatting check. Then the whole build should fail and make the executor will be available for other jobs. No need to finish "Slow tests 1", "Slow tests 2" and "Fast tests 2"
Might be related to JENKINS-18177 ("Allow to cancel both the flow and all running builds").
This feature is also mentioned in a comment, sep 13 2012:
https://wiki.jenkins-ci.org/display/JENKINS/Build+Flow+Plugin?focusedCommentId=63931160#comment-63931160
[JENKINS-21199] Fail fast - When one parallel job fails, fail the flow job (and optionally cancel the rest)
Hallvard Nygård
added a comment - I also see this as an option that is default off due to the reasons you describe.
In our case the fast tests are unit tests and format checking. These are typically easy to fix. We use a Gerrit setup so that a commit must have green tests in Jenkins before passing into the master branch. Fast tests can run for about 1 minute. Slow tests can run for about 10 minutes. Waiting 10 minutes for it to finish is 9 minute waste when we know after 1 minute that it will fail (due to you missing a space after a if statement - and then failing the format checker).
Hallvard Nygård
added a comment - I also see this as an option that is default off due to the reasons you describe.
In our case the fast tests are unit tests and format checking. These are typically easy to fix. We use a Gerrit setup so that a commit must have green tests in Jenkins before passing into the master branch. Fast tests can run for about 1 minute. Slow tests can run for about 10 minutes. Waiting 10 minutes for it to finish is 9 minute waste when we know after 1 minute that it will fail (due to you missing a space after a if statement - and then failing the format checker). +1
Failing and cancelling a parallel block as soon as one inner block fails would be a very useful feature indeed. Either as an option on the parallel block, or as a new DSL command, as long as the idea is implemented.
It's easy to envision the use cases for both:
- Failing fast is useful when you know that a single failure will cause subsequent failures, eg a particular package build fails, so of course deploying a full new release will fail
- Not failing fast is useful when you want to run a battery of independent tests
A C
added a comment - - edited +1
Failing and cancelling a parallel block as soon as one inner block fails would be a very useful feature indeed. Either as an option on the parallel block, or as a new DSL command, as long as the idea is implemented.
It's easy to envision the use cases for both:
Failing fast is useful when you know that a single failure will cause subsequent failures, eg a particular package build fails, so of course deploying a full new release will fail
Not failing fast is useful when you want to run a battery of independent tests
Christian Kerth
added a comment - +1 this would really be helpful. I'm running tasks with huge differences in runtime using the parallel mechanism.
Christian Kerth
added a comment - +1 this would really be helpful. I'm running tasks with huge differences in runtime using the parallel mechanism. +1 We have several cases where we want to "fail fast" during a set of parallel tasks.
Max Ammann
added a comment - This has been implemented as `failFast`: https://jenkins.io/doc/book/pipeline/syntax/
Max Ammann
added a comment - This has been implemented as `failFast`: https://jenkins.io/doc/book/pipeline/syntax/ 
I can see where you might want this functionality but it should be optional. When I run a CI build, I want to see all failing tests, not just the first test that failed. Sometimes seeing the other failures can give you clues about the underlying problem. Sometimes there was more than one defect introduced and somebody can get started on the second one now instead of not realizing there's a problem until after the next testing cycle.