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

     

    usecases:

    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: 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:
    requires:
    - 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.

  • 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. 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.

  • 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?