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

[William Jimenez < >]

We're using an automated CI process to deliver cookbooks to our chef server from source, that essentially runs berks upload. Having the Berksfile.lock in source is important so the CI tool uploads the same version of deps we're developing against locally. 

On Fri, Feb 13, 2015 at 5:28 AM, Torben Knerr < " target="_blank"> > wrote:

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