CircleCI Ideas

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.

  • Avatar32.5fb70cce7410889e661286fd7f1897de Guest
  • Mar 30 2018
  • Taking votes
  • Attach files
  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest 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


  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    August 16, 2018 15:52

    Copying over from:


    Building upon [the discussion here](, 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`]( 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]( 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.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest 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.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    07 Mar 00:25

    This is important for a lot of projects that test against HEAD of an upstream project, e.g. 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.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    09 Mar 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!
  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    20 Mar 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.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    29 Mar 17:20

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

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    23 Apr 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.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    07 Jul 06:06

    Important for cleaning up resources if the previous jobs fail.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    09 Jul 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. 

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    11 Sep 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?