CircleCI Ideas

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)

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

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    June 12, 2018 23:53

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

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

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

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

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

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

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    03 Aug 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).