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

[AJ Christensen < >]

Yo,

On Thu, Feb 12, 2015 at 9:25 AM, Hajducko, Steven < " target="_blank"> > wrote:

We've been having a discussion lately about whether to include Berksfile.lock in our dev branches for our cookbooks.  Right now, I've only been including them in the stable branch. I've seen several other threads ( not on this list ) about this and opinions seem to be back and forth.  Also, since the berks generators put Berksfile.lock into the .gitignore, it seems the opinion of Berks is to *not* include them.

I see the advantage of including them in the dev branches as providing an identical environment for anyone collaborating on the cookbook - but it seems like the Berksfile itself and the metadata.rb constraints should be enough to provide a 'close enough' environment.

What are the disadvantages of including the lock files?​  What do you typically do for your cookbooks?

Git ignoring the Berksfile lock, IME, relies exclusively on hosting your own internal Supermarket or Chef Server Cookbook/Universe API for Berkshelf to resolve against. In mega-repositories using Berksfile as an assembly mechanism, I prefer to check in the lock file, too.

Relying on Berksfile constraints and metadata constraints and ad-hoc resolution against the global Supermarket is a sure-fire road to pain. CI can mitigate this somewhat and is great for uploading assets into the previously mentioned behind-the-firewall Supermarkert/Universe installations.

I currently use Solo and deploy a cookbooks directory via Git. You don't even need Berkshelf. Every installation has different requirements.

cheers,

--aj