This is actually something that we've been discussing at my workplace. Right now, we have one master repo for all of our cookbooks, each in their own subdirectory. Bamboo is polling this repo and will execute a Rake task on updates to push out new changes via Berkshelf, where the cookbooks are listed using the 'rel' tag (assuming it passes knife cookbook test on each of the cookbooks). We also have a secondary scheduled job that runs foodcritic/rubocop and reports on the results.
Given that we're only using this repo for our own internal cookbooks which are too specific to be of any use to anyone else (even if Legal would allow us to share them), what are the pros/cons of this approach? It seems like we would lower git contention between members of our team if we broke them out into different repos, but I'm not sure how we would then refactor the CI jobs. One thing I like about this approach as that the only thing we have to do in regards to CI is just to add the new cookbook to the Berksfile and it just works. If we set up Bamboo to monitor multiple repos, that increases the chance that someone will add a new cookbook and forget to monitor that new repo in both Bamboo jobs (pushing and linting). Not to mention that it complicates the jobs themselves which now have to pull in multiple repos-- Berks will handle that fine, but knife cookbook test will need them all checked out to execute, as will foodcritic/rubocop on the linting side, and I definitely like the acceptance criteria of passing knife before being pushed with berks. I don't like the thought of pushing it up to the chef server with potentially broken ruby code.
Now, we could do per-repo Rakefile/Berksfile setups, but that increases the overhead of setting up a new cookbook. And the idea of having 20+ jobs in Bamboo, each for their own cookbook, seems wrong to me.
Thoughts?