On Mon, May 19, 2014 at 10:53 AM, Matt Stratton firstname.lastname@example.org wrote:
Not to go off on a tangent, but I’m curious about a statement in here. You
mention that the cookbook should not be “using git submodules or any of that
What would be the negative reason for putting chef-repo in source control,
and then all cookbooks in their own repos, but putting a submodule of each
cookbook under the cookbooks directory of the chef-repo? I’ve been working
on a few projects where we intended to do this eventually, and just haven’t
done so yet. What issues/problems might I not be realizing?
A submodule is pinned to a particular Git hash, so you wind up in a
whole world of maintenance hell when you want to get a consistent
state for your top level. example: if I ‘git submodule update’ to get
to a new hash, I’m immediately impacting everyone.
I usually set things up like this for customers:
- chef-repo [its own Git module, with a .gitignore containing cookbooks/*]
- cookbooks (empty directory, maybe with a README.md in it
explaining why it’s empty)
and then a Git module per cookbook.
The workflow for someone starting with Chef at that company would be:
- Clone chef-repo
- cd into cookbooks, clone individual cookbooks as needed
Yeah, there’s Berkshelf, and upstream dependencies, and all that jazz
I haven’t accounted for. But when people are first starting out, the
most important thing they are interested in doing is to start writing
some Chef code immediately without having to learn a pile of tools.
[ Julian C. Dunn email@example.com * Sorry, I’m ]
[ WWW: http://www.aquezada.com/staff/julian * only Web 1.0 ]
[ gopher://sdf.org/1/users/keymaker/ * compliant! ]
[ PGP: 91B3 7A9D 683C 7C16 715F 442C 6065 D533 FDC2 05B9 ]