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
  • jo mo commented
    24 Apr 02:47pm

    Use case for me is a smoke test job that runs against master before deploy (should fail and prevent further jobs running , namely build and deploy) but also runs on a nightly schedule in which case it should be able to fail and still have the following job run to notify devs of the failure

    • steps requiring failure to cease flow

    - hold-staging:

    type: approval

    requires:

    - smoke-test

    • job requiring failure to continue flow


    scheduled-smoke-test:

    triggers:

    - schedule:

    cron: "5 8 * * *"

    filters:

    branches:

    only:

    - master

    jobs:

    - smoke-test

    - smoke-test-notification:

    requires:

    - smoke-test

  • Kos Huang commented
    7 Apr 09:56am

    This will be huge for us!

  • graham booth commented
    19 Feb 12:04am

    any news on this??

  • b g commented
    14 Feb 11:50pm

    Pleaseeeee

  • Rob Duncan commented
    7 Feb 07:49pm

    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.

  • A commented
    26 Nov, 2019 02:43pm

    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

  • Deniss Sazanovs commented
    22 Nov, 2019 12:13pm

    +1.  Very important for testing purposes

  • Patrick Cummins commented
    5 Nov, 2019 09:53pm

    +1

  • Kevin Roulleau commented
    31 Oct, 2019 10:03am

    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.

  • A commented
    29 Oct, 2019 03:51pm

    especially important in automation

  • Robert Cooper commented
    11 Sep, 2019 04:45pm

    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?

  • Christopher Mera commented
    9 Jul, 2019 04:11pm

    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. 

  • Bin Xia commented
    7 Jul, 2019 06:06am

    Important for cleaning up resources if the previous jobs fail.

  • Malte Isberner commented
    23 Apr, 2019 09:20am

    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.

  • Vlad Borg commented
    29 Mar, 2019 05:20pm

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

  • Paris Yee commented
    20 Mar, 2019 05:00pm

    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.

  • andre nakkurt commented
    9 Mar, 2019 12:12am

    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!
  • Daniel Compton commented
    7 Mar, 2019 12:25am

    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.

  • Ed Warnicke commented
    17 Oct, 2018 07:21pm

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

  • Rob Phillips commented
    16 Aug, 2018 03:52pm

    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.

  • Load older comments
  • and 131 more