[chef] Re: Re: Re: Re: Workflow of Making, Testing and Using a Cookbook?

[Matt Stratton < >]

I knew there was a reason, other than "submodules can confuse the heck out of git newbies, and most of our customers are new to git". Your recommended structure is similar to the one I've been using (we actually put the chef-repo is a specific subdir named after the chef org, and then we put the cookbooks into individual git modules in a cookbooks dir at the same level as the chef-repo, as we have rake tasks we put in the chef-repo for our customers to do things like create new cookbooks (but with chefspec, berks init, etc).

On Mon, May 19, 2014 at 10:06 AM, Julian C. Dunn < " target="_blank"> > wrote:

On Mon, May 19, 2014 at 10:53 AM, Matt Stratton < "> > wrote:
> Julian,
>
> 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
> funny business".
>
> 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/*]
  + roles
  + environments
  + data_bags
  + 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

--
[ Julian C. Dunn < "> >          * 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       ]