[chef] Re: Re: Re: Re: ChefDK and CI

[Dave Kichler < >]

I've just recently dealt with this issue myself.  We use ChefDK as part of development but since I don't come from a strong Ruby background I was struggling to get just the right Gemfile to correctly setup dependencies on CI to successfully execute all of our test suites (both chefspec/rspec and test-kitchen/serverspec suites).  Our CI boxes are of course managed by Chef so I simply added the ChefDK cookbook (https://github.com/RoboticCheese/chef-dk-chef) to the runlist for CI nodes and voila, an environment that behaves identically to my development machine.  ChefDK can then be enabled on a per-job basis by manipulating the PATH for that job only (using the handy script that comes with the DK).

Cheers,

Dave

On Fri, Oct 10, 2014 at 10:19 AM, Lamont Granquist < " target="_blank"> > wrote:

On 10/10/14, 8:22 AM, Paul C wrote:

it extends slightly beyond chef to all the test tooling ( rubocop / chefspec / serverspec / etc ) and making sure they're all at the same version in CI as in local dev.

Maybe I'm overcomplicating it for myself and it could be solved by saving a Gemfile.lock,  but I was under the impression this is considered a bad thing ?

I don't see how its a bad thing.  If you have needs to pin different things for different projects I think you're probably going to be necessarily forced into using Gemfile.lock's, and in a large enough Enterprise it'll most likely be difficult to get everything pinned in lockstep.  Then once you pin your gems you need to pin your underlying rubies.  ChefDK will probably be useful for that, along with providing the chef command line tool which eventually you'll be wanting to 'chef push' or 'chef promote' from your CI.  But you could manage your own rubies in rvm and install the chefdk gem in your bundle and that'll all work as well, you just accept more responsibility in that case (we only really support the chefdk gem on the ruby that we ship with, for example).