Support for conditional jobs in workflows

Circle 2.0 has been a huge improvement over Circle 1.0 - thank you for all the new features! One thing that would really unlock a ton of power, though, would be adding support for conditional jobs.

Currently, in a workflow, you can specify "job B requires job A to succeed". But you can't author flows like "only run Job B if Job A succeeds, otherwise don't run it." There's a critical difference between these two semantics. In the first flow, job A is expected to usually succeed, and the build should be marked as failing if it doesn't. In the second case, Job A not succeeding is *expected* and shouldn't cause the build to fail.

Perhaps an easy way to wire this would be to have jobs that aren't treated as "success" or "failure", but rather always succeed and just report the status to an environment variable. This would allow authoring a job that could kick off if a variable is set (or some similar mechanism)

  • Tom Wilson
  • Feb 6 2018
  • Taking votes
  • Attach files
  • Maksim Iakunin commented
    30 Jul 09:23


  • Danning ge commented
    27 May 20:45


  • Jonathan Machado commented
    December 06, 2019 15:53

    This is one of the main missing features in CircleCI.

  • Antonio De Almeida commented
    November 27, 2019 07:12

    Azure DevOps does this out the box in their azure-pipelines.yml files. Surely this can be done here?

  • Guest commented
    November 07, 2019 14:10
  • Guest commented
    November 07, 2019 14:09

    + 1 


    here is an example of a very simple use case of parallel test execution with a follow up job to merge test results from parallel test jobs.


    Pictures say more than thousand words:


            - build-artifacts:
            - test-suit-1:
                    - persist-test-results
            - test-suit-2:
                    - persist-test-results
            - test-suit-3:
                    - persist-test-results
            - test-suit-3:
                    - persist-test-results
            - ROBOT-REPORT:
                      - test-suit-1
                      - test-suit-2
                      - test-suit-3
                      - test-suit-4
                  ignore_previous_status: true
                      - attach-test-results



  • Brandon Page commented
    August 03, 2019 18:29


    My project is an SDK with 6 individual libraries.  Currently I have a single setup job that fans out into tests for each library in parallel.  In that setup job I look at the paths of the modified files in the PR and determine which libs have changed.  Unfortunately, I still have to pass that info to each of the jobs and let them determine if they should run or not.  It would much cleaner and much clearer (epically to external contributors) if only the necessary jobs started and showed up as having ran on the PR. 


    I've been hoping this would happen for a couple years now, hope it eventually happens.  I understand the challenge however, since it would require some sort of processing/shell execution at parsing time (before execution time).   

  • Kei Ito commented
    March 16, 2019 03:04

    We can replace the current filters with "allow-failure" jobs:

    - build
    - test: {requires: [build]}
    - lint: {requires: [build]}
    - is-tagged: {requires: [test, lint], allow-failure: true}
    - deploy: {requires: [is-tagged]}
    - is-not-tagged: {requires: [test, lint], allow-failure: true}
    - deploy-canary: {requires: [is-not-tagged]}

    It will be better than adding options like "AND", "OR" to current filters.

  • Eddie Bachle commented
    March 05, 2019 14:16

    Our interest in this feature comes from a terraform execution in CI perspective.

    I'd love to have

    - plan job
    - approval job
      - filter: {{ conditional - only run if terraform plan is not empty }}
    - apply job
      - requires: approval

    Without this we get developers in a habit of rubber stamping terraform approvals when we badly need them looking at it to ensure we're not passing through destructive actions.  Ideally a promotion pipeline helps with this, but doesn't eliminate it.  Keeping the noise down by having conditional jobs in a workflow (or even just conditional approvals) would be tremendous.

  • Nick Palmer commented
    November 30, 2018 00:01

    Very much needed for monorepos where there may be no changes to one portion of the repository and we can detect that and skip useless work.

  • James Irwin commented
    November 09, 2018 20:02

    I have a similar need to not bother running a test if some command conditional is true.  In particular don't bother running some tests if a certain directory has not changed compared with master branch.  I'd suggest within workflows have a


       conditional: {{ command that evaluates to 1 or 0 }}

  • Edward Rudd commented
    July 04, 2018 16:24

    We have a scenario where we want a job to ALWAYS run even if the previous steps failed.. but it should only run once those previous ones are completed.. e.g. our flow is like this.



    backend testing -> deps: [checkout], parallel: 2

    frontend testing -> deps: [checkout]

    summary -> deps: [backend, frontend]


    The summary job takes all the output from the backend/frontend tests and combines them (especially for the parallel jobs in the backend) and spits out artifact links to our github PR.   Right now if one of the backend nodes fails we never get that output to the PR.

  • Nate Rook commented
    June 12, 2018 23:53

    This would be extremely helpful for those of us with monolithic repositories ("monorepos").

  • Ethan Fremen commented
    March 15, 2018 19:51

    this would be seriously helpful, I want to skip redundant work/reuse artifacts from prior branches and there's no way to spell that.