If you've recently forked the ey-cloud-recipes on GitHub and then had issues managing and deploying multiple projects with disparate dependencies using the single forked gem, then we have a solution that has worked well on a recent project.
We've tucked the cookbooks directory underneath our Rails project. To apply Chef changes, we installed the 'engineyard' gem and us 'ey recipes upload' and 'ey recipes apply' from within our Rails project.
Upside, everything you need to know about the project is local to the project.
. ├── Gemfile ├── Gemfile.lock ├── README.md ├── Rakefile ├── app ├── cookbooks │ ├── main │ │ ├── attributes │ │ │ └── recipe.rb │ │ ├── definitions │ │ │ └── ey_cloud_report.rb │ │ ├── libraries │ │ │ ├── ruby_block.rb │ │ │ └── run_for_app.rb │ │ └── recipes │ │ └── default.rb │ ├── redis │ │ ├── README.rdoc │ │ ├── recipes │ │ │ └── default.rb │ │ └── templates │ │ └── default │ │ ├── redis.conf.erb │ │ └── redis.monitrc.erb │ └── sunspot │ ├── recipes │ │ └── default.rb │ └── templates │ └── default │ ├── solr.erb │ └── solr.monitrc.erb
Having automated configuration live with your source code is the way things should always work. Chef recipes are just code that makes your code run. What makes today's code run may be different from what makes last month's code run. If you deploy last month's code for some reason, it should work just as well as it did when you deployed it last month.
I'll certainly try this out if I end up on an EY Cloud project.
Have you added them as a submodule or did you just commit them as part of your project?
We didn't use submodules. We're treating the Chef cookbooks/recipes as source, similar to app source.
Great idea. Why we have always kept these in separate repos is now a total mystery to me.