Allow Job Failures
L
Lev
Use Case: We have some Jobs in our workflows, eg linting of code. If these fail the whole workflow shows as Failing, forever. Is there any way we can mark certain Jobs as not important? Would be nice if these non-important jobs would show with status= warning and not failed.Similar (but not the same) as: https://circleci.com/ideas/?idea=CCI-I-216
CCI-I-646
Dmitry Ryadnenko
This will be useful for us for several cases. Including.
- Running monitoring jobs, like jobs that measure build times. Sometimes there is no reason for the whole build to fail if such job fails.
- Running tests suites which are expected to be flaky. There can be value in running such suites even if it's expected that they will fail each run. Our QAs can look at the results of these suites and rerun the failed tests manually. But we don't want to fail the whole build when suites like this fail.
Of course we can set up GitHub to make obs like this non-mandatory for merging PRs. Still it will be useful to see workflows that contains failed jobs like that as not failed in the list of workflows. So we can more correct insight of the overall health of the build system. And it would be nice for these workflows to not count towards "build failed" statistics in the Circle CI "Insights" page.
S
Steve Plate
What might be a good option is to allow the rules to decide if a step should return failure or warning. For instance, in python, you could return a specific code to denote warning instead of failure.
D
DavidBodow
Would be useful for cases such as linting or checking specs always hit the VCR cache.
R
Ryan French
For our use-case, we are implementing vunerability image scanning on our docker containers, and it would be extremely useful to be able to fail the job if there are critical vulnerabilities, or simply have a visual warning in the workflow, such as a yellow box instead of a red/green one, if there are medium level security issues.
T
Tristan Casebeer
I agree with this. Having a warning status would add more flexibility to our CI processes and would allow us to communicate non-critical issues to our developers in a less disruptive manner.
P
Peter Berg
+1 for warnings
Aria Stewart
This would be very useful for integrating long-running or partially-passing test suites. We are building a browser test suite but the run times will never be acceptable for every build. We'd like to run them intermittently, but only warn that they failed, not fail the whole build.
C
Chantal Broeren
So the overall test won't fail, but you would be able to see whether a job is failing.
C
Chantal Broeren
We have a large application with an important dependency. To be prepared (just as a warning) we want our application to be tested with coming releases of that dependency (beta and canary). It doesn't matter for the current state of our application, so it may not fail and should deploy it.