Allow for top level ".circleci.yml"

Allow for top level configuration file. Requiring a folder seems unnecessary in most cases.

This would bring it more in line with most other configuration files and pollute the repository less.

  • Guest
  • Apr 13 2018
  • Not planned
  • Attach files
  • Guest commented
    April 19, 2018 22:21

    Fair enough. We had to jump through a bunch of hoops to allow for folder configuration, but it's now implemented - so I guess we're ok with leaving this. Thanks for responding

  • Nathan Dintenfass commented
    April 19, 2018 21:12

    It's less about whether we can check, which would be trivial, it's the documentation of the different options and supporting them since they'd have different behaviors once we have the rest of the things we plan to add to the .circleci folder. There's also more overhead than you might think in retrieving files prior to your build starting (which we need to do for configuration), so there are some operational concerns in the "cons" column for us on this. 

  • Guest commented
    April 19, 2018 19:56

    I'm not sure what the concern is with having multiple config file names / locations? E.g. the load logic should check (1) .circleci (2) .circleci.yml (3) .circleci/config.yml

    I'm not sure why it is a concern to support different files? A lot of other tools do it.

  • Nathan Dintenfass commented
    April 14, 2018 04:55

    Understood. In this case we have to ask that you tolerate the directory, so we can allow for some interesting new things coming down the pipe without having two different places for your config to live. 

  • Jeff S commented
    April 13, 2018 22:17

    ... as I was saying before I hit "Post" by accident ...

    for example in a node project you can have a circle config, travis config, babel config, flow config, serverless config, editor config... the list goes on. If everyone were to have a directory based top level format, that doubles the amount of entities in your project directory.

  • Jeff S commented
    April 13, 2018 22:12

    Nathan, I think what he means with the "pollution" is that it's two entities, the directory and the config file, instead of one, just the config file.

    Some projects can have a ridiculous amount of config files

  • Nathan Dintenfass commented
    April 13, 2018 22:05

    We have some plans for extended features of configuration that will live in other files. To avoid having too many different flavors of configuration setup we are likely to stick with the folder. Curious to hear more about the "pollution" of a folder vs. a file, though.