[chef] Re: Re: Berksfile.lock commit in dev branches

[Torben Knerr < >]

Hi Matt,

as you said, we are as well doing it only for the top-level cookbooks
(think of environment cookbooks but using metadata.rb instead of
environments to lock the dependency graph). Since we are using mostly
chef  solo / zero having the Berksfile.lock checked in is enough.

I also experimented with generating / dynamically reading metadata.rb
entries from the Berksfile.lock for chef client / server use, but it
was just an experiment and YMMV:
https://gist.github.com/tknerr/4e3236d00ceba917abea

Here's an example "top-level cookbook":
https://github.com/tknerr/sample-toplevel-cookbook

And if you are using Vagrant you might be interested in this, too:
https://github.com/tknerr/vagrant-toplevel-cookbooks

Last but not least, I believe that the new Policyfile mechanism tries
to solve the issues we have, but I have not tested it yet and so I
can't speak of it...

Cheers,
Torben

On Wed, Feb 11, 2015 at 9:43 PM, Matt Juszczak 
<
 >
 wrote:
> Hey,
>
>> What are the disadvantages of including the lock files?  What do you 
>> typically do for your cookbooks?
>
> This was a big debate for us too a few weeks ago. We’re using Berksflow so 
> any application/environment cookbooks get the Berksfile.lock checked in. 
> However, other cookbooks (like wrapper cookbooks) don’t. We version peg 
> *everything* in metadata.rb. Either way (whether you check-in 
> Berksfile.lock or not), there’s still no guarantee what you’re testing 
> locally is 100% matching production (since production only looks at 
> metadata.rb, unless you’ve version pegged an environment with something 
> like Berksflow).
>
> -Matt