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.
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.
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
... 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.
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.
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.
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.
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
You won't be notified about changes to this idea.