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.

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
  • Future consideration
  • Attach files
  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    15 Mar 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
    12 Jun 23:53

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

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    04 Jul 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
    09 Nov 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
    30 Nov 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.