Option to allow failures in Fan-In/Out Workflow

The requires tag in workflows really limits what is possible. Requires makes a lot of sense for the deployment scenario used to demo it, but waiting for a group of jobs to complete (pass or fail) should be an option.

Scenario: Setup -> Run multiple sets of tests in parallel -> Combine test results/coverage results/artifacts and report to PR

That scenario above isn’t possible because if a single test fails in any of the jobs running in parallel the the fan-in step won’t run.

  • Brandon Page
  • Mar 30 2018
  • Taking votes
  • Attach files
  • Sandeep Ganapatiraju commented
    July 09, 2018 23:41

    this is super important feature for us too



    1.downstream job to rerun one time failed tests from original job. 

    2. downstream job has to post combine testresults back to pr


  • Rob Phillips commented
    August 16, 2018 15:52

    Copying over from: https://discuss.circleci.com/t/continue-running-other-jobs-after-required-job-fails/24334


    Building upon [the discussion here](https://discuss.circleci.com/t/could-selected-jobs-be-configured-to-generate-a-warning-instead-of-pass-fail/22395/4), I'd like a way for a **job** to run even though a previous **job** in the workflow has failed in some way.

    I know about [`when`](https://circleci.com/docs/2.0/configuration-reference/#the-when-attribute) for a **step**, but there doesn't seem to be something like this for a workflow's **job**.

    We're currently having to do something like `test_lib || true` to make the CI step pass even though it's actually a failure. That's definitely a code smell to us.

    Example use case:

    # this is a `job` in CircleCI's vernacular
    - report_build_statuses:
    - install_gem_dependencies
    - lint_with_danger
    - build_app
    - test_lib
    filters: *ignore_certain_pr_builds

    ## Expected Behavior

    In this scenario, I'd like the `report_build_statuses` job to run even though the `test_lib` job failed some tests (and it depends on that job running, either successfully or not, before it can run).

    So this would:
    1) Report back to Github that `test_lib` failed its tests
    2) Run `report_build_statuses` which would summarize those failings in a GitHub comment (we do this using [Danger](http://danger.systems/ruby)) and avoids us having to dig through CircleCI logs to figure out what failed

    ## Existing Behavior

    Currently, it just fails the `test_lib` job and then never runs `report_build_statuses` because apparently the `requires` keyword has the requirement that each job _succeeds_ rather than just requiring that each job runs.

  • Ed Warnicke commented
    October 17, 2018 19:21

    This is super important for clean up jobs that have to run even if a step in the workflow fails.

  • Daniel Compton commented
    March 07, 2019 00:25

    This is important for a lot of projects that test against HEAD of an upstream project, e.g. github.com/clojure-emacs/cider. We want to know as soon as possible if things are breaking against unreleased versions of Emacs, but at the same time, we don't want to block merging, or report a total failure. Sometimes those broken things may not be our fault, and are later fixed upstream.

  • andre nakkurt commented
    March 09, 2019 00:12

    This is important for us for the same reason Ed mentioned - "clean up jobs that have to run even if a step in the workflow fails".

    Hope voting on this makes a difference and this feature will be supported!
  • Paris Yee commented
    March 20, 2019 17:00

    We would also really like this feature as well. We have different test suites running in different jobs and would like to be able to aggregate results in a final job regardless of the pass/fail status of the "required" jobs.

  • Vlad Borg commented
    March 29, 2019 17:20

    Also interesting in that. As a final step of workflow we want to report to some external systems.

  • Malte Isberner commented
    April 23, 2019 09:20

    Important for us as well.

    We have resource provisioning jobs that run in parallel to the build stages since resource provisioning takes long-ish. We do some light checks (`go vet`) before provisioning, but these are not a 100% guarantee that build won't fail. We would need this feature to ensure that resources get cleaned up in every case.

  • Bin Xia commented
    July 07, 2019 06:06

    Important for cleaning up resources if the previous jobs fail.

  • Christopher Mera commented
    July 09, 2019 16:11

    The ability to define a job within a workflow to run regardless of the failures in a previous job is a useful feature. It would be great to work similarly to how the "when: on_fail" key works when a step fails within a job. The reason for this in the pipeline design, it makes sense for many of us to run cleanup or postprocessing jobs at the end of the runs. 

  • Robert Cooper commented
    September 11, 2019 16:45

    There hasn't been an update on this idea for a couple of months... can someone from CircleCi weigh in to offer a workaround or let us know whether it will be considered for implementation?

  • A commented
    October 29, 2019 15:51

    especially important in automation

  • Kevin Roulleau commented
    October 31, 2019 10:03

    I'd also like to see this feature implemented.

    Here is my use case:

    I've setup parallelisation for end to end tests, so I've got 4 jobs that run and produce test report files.

    Then after all the tests are done, and regardless of their success or failure, I need to combine all those test report files and compile them into a centralised test report website (I am using allure test report).

    This is because for E2E tests it is very important to have a comprehensive report, with logs and screenshots. The junit thing is not sufficient for this kind of project.

  • Patrick Cummins commented
    November 05, 2019 21:53


  • Deniss Sazanovs commented
    November 22, 2019 12:13

    +1.  Very important for testing purposes

  • A commented
    November 26, 2019 14:43

    We would like to add tests, that are still under development. getting a notification on their failure is important but they should not be blocking the pipeline yet

  • Rob Duncan commented
    07 Feb 19:49

    There's been a fair amount of comments on this and no word from CircleCI.


    Having worked with thousands of CCI pipelines this has been a huge pain point for us.

  • b g commented
    14 Feb 23:50


  • graham booth commented
    19 Feb 00:04

    any news on this??