Specify a config.yml file per branch with config.yml as the fallback


We’d like to avoid running tests on our release branch and only do a deploy, we currently have a solution that does a check against ${CIRCLE_BRANCH} which works for the most part although it makes the YML file pretty messy.

However, there is no way from what I can tell to avoid the setup_docker_engine on some branches but not on others, which is obviously a waste of time/resources.

I think a great solution would be to have a fallback naming pattern for the config.yml file, which would allow you to specify config.releases.yml that took precedent when the branch was "releases’, is something like that currently possible?


You can also remove the parts from the config file that you don’t need on that branch’s version of the config file.


That doesn’t really work for us as we branch from the deploy branch to create new PR’s, so the deploy only changes in the config.yml would come along with that branch anyway. Also, I see other issues here, if you wanted to create a PR to adjust something that happens on deploy, you couldn’t because the config is only in the deploy branch itself. Or if you reproduced it in your branch each time you wanted to make a change, you’d have merge conflicts.


To answer your original question, this isn’t currently possible. We have work in our the pipeline to give finer grained controls over jobs, though this will likely be after 2.0 hits open beta.


Might be worth moving this into feature requests? Otherwise, if you have an alternative solution coming that will solve the same problem, happy to just close the issue. Thanks.


Here’s an alternative that works right now.

version: 2

      - image: ruby:2.4.0
    working_directory: /my-project
    parallelism: 2
      - checkout

      - run:
          name: Some tests
          command: |
            echo "tests run here"

      - deploy:
          name: conditionally run a deploy job
          command: |
            curl --user ${CIRCLE_API_TOKEN}: \
              --data build_parameters[CIRCLE_JOB]=deploy \
              --data revision=$CIRCLE_SHA1 \

      - image: ruby:2.4.0
    working_directory: /
      - run: echo "deploy section running"


  • This will make one push potentially trigger multiple builds (a launch build, then a deploy build)
  • using the deploy step is important so that you don’t trigger N builds, where N is your parallelism level
  • setup_remote_docker should go in the deploy job section.
    • I should have renamed the job section to anything else but deploy just to avoid confusion with the deploy step. This would also require modifying the build_parameters[CIRCLE_JOB]=deploy parameter passed into the job.


Ahh, the API supports running sections other than the default “build” section, that is very good to know. Thanks for the example, pretty ingenious approach.

I’ll have to discuss with the team, see what they think to having two builds to overcome a messy YML file.


‘Soon’ (no ETA at present) we’ll be adding a much more elegant way to manage multiple jobs. This is a temporary workaround for the current features available during Beta.


I think this is a great idea and was writing a new thread with the exact same request.

For me, deploy, integration and pr-testing is entirely different. One mocks databases and other talks to third party sources. To set this up for all jobs is just killing cpu cycles and time. Looking for $branch.yml and fallbacking to circle.yml is such a simple and useful solution.


That does seem simple, but almost too-much so. A lot of people name branches with forward slashes, which would cause issues immediately.


I also use forward slashes but wouldn’t have a problem adjusting to a ruleset you define. The customer isn’t always right in this case. release/2.0 vs 2.0 could be a perfect compromise if you care enough about build times, don’t you think?

Edit: come to think of it, i kind of even answered my own question. The prefix could just as well work as identifier. Something like:

release/2.0 -> tries:

  • release/2.0.yml -> “file doesn’t exist or invalid”
  • release.yml -> “file doesn’t exist”
  • circle.yml -> “file doesn’t exist”
  • error

Finally, the introduction of a config.yml (configures circleci) and test.yml/release.yml/integration_test.yml) (defines/executes a “PR run” [to avoid the ambiguous word “job”]) would seem a logical next step if this is happening.