Optional build steps


#1

In our Circle 1.0 config, we used deployments to perform a number of optional steps based on the current branch name and tag. In Circle 2.0, from what I’ve seen in examples, the suggested approach is to simply have if conditions in a batch script.

For readability however it would be even nicer if you could specify a condition for each step, and have that step not appear at all in the UI unless the condition was met.

This also means that you could add a condition on steps other than “run”. For example, some, but not all, of our branches require Docker, so we have a setup_docker_engine step, but for the builds where Docker is not required, that adds a delay for no reason.

Any plans in this direction? Or an existing way of making built in steps such as setup_docker_engine optional?

Cheers,
Kristian


Create separate steps/jobs for PR/Forks versus branches
#2

Yes, we have definitive plans to support conditionally running certain steps.


#4

Along these lines, I’d sure love a way to run a step only if some specified paths contents have changed.

Use cases:

  • A long running test suite that I don’t want to run if the code it tests hasn’t changed.
  • Mono-repo setups where there are many projects in one repo, I’d like to only test what needs to be tested.

I imagine something similar to the cache system to drive this. As a matter of fact, I think I can abuse the cache system to meet my first use case.


#5

Great! We’re definitely holding off on our 2.0 migration until this exists, we use it very heavily.


#6

Definitely a must have, as I mentioned in another thread already.


#7

I have a similar setup to @brendanjerwin’s use cases:


https://circleci.com/gh/decidim/workflows/decidim/tree/circleci-workflows

My idea is to create a job for each folder in the repo and skip a job if the git branch does not modify any file from that folder. I see I can run some steps conditionally based on the exit code of the previous step:

https://circleci.com/docs/2.0/configuration-reference/#the-when-attribute

So I thought about creating a first step that gets the list of modified files in this branch and then check if I need to run the tests for a job or not, but I fear this will make the build fail.

Can we skip a step based on the output of a script without making the build fail, with what is currently implemented?

Thanks!


#8

For our use case it would be great if the conditional steps took the same filters as workflows, for example:

jobs:
  flow:
    steps:
      - run:
          name: Only run on master
          command: foo
          filters:
            branches:
              only: master

workflows:
    version: 2

build_test_deploy:
    jobs:
      - flow
      - downstream:
          requires:
            - flow
          filters:
            branches:
              only: master

So that we can re-use the filters.


#9

I’d also like to know if this feature could be implemented. For our use case it’d save us a ton of time the ability to prevent a job from running. We wouldn’t need to wait on attaching workspaces and setting up the remote docker service if jobs could exit early, without failing the build, based on the exit status of a script or some other mechanism.

Using throwaway git branches results in poor developer experience due to the lack of visible feedback on pull requests, and it feels like a hack. Failing the job early does provide feedback but just feels confusing.


#10

Any update on this feature?


#11

Any updates?


#12