Support for conditional jobs in workflows
under review
T
Tom Wilson
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)
CCI-I-216
Nathan Fish
Would more flexible requires functionality solve for this issue?
https://circleci.canny.io/cloud-feature-requests/p/option-to-allow-failures-in-fan-inout-workflow
It would give you more flexibility to run jobs when they fail or regardless of the outcome, like when they are completed.
J
J. Casalino
Nathan Fish Flexibility as proposed could be helpful to some as a first step, but it's still not a replacement for a fully-fledged "when" conditional with logical AND/OR/NOT support. I think building a job flow only with "requires:" would actually create more confusion and duplicate code because in many cases you'd still have to account for each permutation depending on the outcome of two or more jobs.
Bruce Tan
Nathan Fish No this doesn't address this issue, we need
when
conditions in jobs. Would be much appreciated if you could consider prioritising it as it has been a pain point for us when working on circle ci configsNathan Fish
Bruce Tan:
Nathan Fish
J. Casalino: Got it. So my thought would be to introduce a new tag for "when" statements called "expression" and you could use expressions (like expression based context restrictions) to create conditionals from pipeline values.
Expression based context restrictions https://circleci.com/docs/contexts/#expression-restrictions
Pipeline values https://circleci.com/docs/pipeline-variables/
- when:
expression:
- pipeline.git.branch == "main" and not job.ssh.enabled and not (pipeline.config_source starts-with "api"")
Thoughts?
Nathan Fish
I would also want to expand this to cover steps, jobs and workflows.
J
J. Casalino
Nathan Fish Yes, exactly. So extend
when
expression support to steps, jobs, and workflows, then allow an expression based on pipeline values or results of prior steps/jobs/workflows which have already run (or have been skipped). I could also see an argument to add a couple more operators like "ends-with" and "contains".I think you'll have to be careful not to break existing logic statements people have already written in dynamic config [1], but the
expression
approach will be much more flexible for everyone. I would suggest supporting, but deprecating, the old method to avoid further confusion. You could even give WARN-level hints on how to update such a statement in the new syntax.[1]
https://circleci.com/docs/configuration-reference/#logic-statements
Bruce Tan
Nathan Fish Does expression support working with pipeline parameters?
Nathan Fish
Bruce Tan the proposal here would be pipeline values and not pipeline parameters. I'll discuss with the team if pipeline parameters could be included as an option.
T
Tyler BoddySpargo
I just wanted to share that I specifically would appreciate job-level support for very similar
when: <logic statement>
syntax to what is available for workflows today. If that can be implemented generically to also support the OP's use-case that would be great, but I personally see a better solution for the OP's case being accomplished by an expanded requires
syntax. For example:`requires: [ { name: <job_name>, when: always }, { name: <job_name>, when: on-fail } ]
Laurynas Pliuskys
Tyler BoddySpargo: yes I have the exact same request!! We have quite a complex workflow with different jobs depending on each other, but we also have a dynamic config implemented, so it would be nice if the complexity of the workflow was preserved (so only have 1 workflow) but only jobs that have `when: << pipeline.parameters.build-serviceX-job >> were run. That way the logic moves to the job level, rather than the workflow level
Tricia Spoonts
Hi all,
Looking at this post, it appears that you have interest in our config. We are making some updates to requires and would like to understand your processes and what formatting makes those most efficient.
Would any of you be interested in doing a formal user-interview with us? This is a 30 minute recorded video call in which we'll talk about requires in configuration and show you some approaches. If you're open to it, please book some time here: https://calendly.com/tricia-circleci/ux-session?month=2020-12 Thank you in advance, hope to learn from some of you.
Tricia Spoonts, Product Design Manager, CircleCI
Owen Hankinson
Tricia Spoonts: Looking for a way to access this feature, has this been added?
Tricia Spoonts
Owen Hankinson: I'm unsure of your use case, but dynamic configuration might be what you're looking for https://circleci.com/docs/using-dynamic-configuration/
Dennis Schridde
I would like for Terraform changes to normally be applied, but for changes to certain Resources to require approval.
I can inspect the Terraform Plan using
jq
and grep
, but what seems to be missing in CircleCI is a way to "hold" the pipeline if my jq | grep
script finds something.L
Liya Ai
under review
M
Maksim Iakunin
+++
D
Danning Ge
+1
J
Jonathan Machado
This is one of the main missing features in CircleCI.
A
Antonio De Almeida
Azure DevOps does this out the box in their azure-pipelines.yml files. Surely this can be done here?
W
Wladislaw Wagner
Example picture of conditional job use case
Load More
→