Submit Your Ideas

We want to hear from you - vote for the features and improvements you'd most like to see, or submit your own ideas if you don't find them already listed.

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
  • Future consideration
  • Attach files
  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    09 Jul 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
    16 Aug 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
    17 Oct 19:21

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