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
    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 4, 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.

     

    checkout

    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.