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

[Adam Jacob < >]

I think this will settle down as Chef DK matures. Clearly, having the DK in the CI env is right, but we need to match up with Chef cliwnt .

On Oct 10, 2014 8:56 AM, "Ranjib Dey" < "> > wrote:

we use the exact same stack that you have mentioned. i.e. chef, chefspec, foodcritic, serverspec (with specinfra-lxc) , and we check in Gemflie.lock, just like any other ruby projects :-)

if you are comfortable with bundler and worked with vanilla ruby projects, bundler route will be better, as you get to control dependencies just like any other ruby projects. ChefDK has an advantage for having baked in tools like berkshelf, which depends on the gecode based dep solver(which takes 15 min to compile using raw bundler), but this wont matter if you are using librarian-chef.

cheers

ranjib

On Fri, Oct 10, 2014 at 8:22 AM, Paul C < " target="_blank"> > 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 ?

On Fri, Oct 10, 2014 at 9:53 AM, Ranjib Dey < " target="_blank"> > wrote:

i think its fine, but chef-client gem or the omnibus will be better. ideally you would like to use the same setup as you use for production. ChefDK is aimed at development, hence it bundles lot more gears than the client itself.

We use chef-client omnibus for production and functional testing under CI. Installation (bootstrap + chef run) is ditto as production. Unit testing pipeline uses raw chef gem (managed via Gemfile/bundler). We ensure that we are bumping up the chef version mentioned in Gemfile is same as bootstrap templates. This is an additional burden, but not a lot a additional work. For you it would mean ensuring same chef version in chefdk and chef omnibus.

regards

ranjib

On Fri, Oct 10, 2014 at 5:43 AM, JayP < " target="_blank"> > wrote:

Ohai Chefs!

We are trying to get more of our team to use ChefDK for their cookbook
development.  If everyone is using ChefDK is it recommended to use ChefDK on
your CI Server agents as well to do the testing of your cookbooks?  All our
repositories have a Gemfile which have some duplicate gems so it wouldn't be
required but my worry is that someone will be using chefdk locally and
potentially see different results in CI.  We are managing our CI agents via
chef so that would mean the chef-client that comes with ChefDK would be used to
provision the host with other things such as vagrant, virtualbox, rbenv, etc.
If folks think it is low risk to use the chef gem for CI instead of ChefDK I
think I prefer that route as it makes it easier to upgrade itself etc.  What
are folks thoughts on this?  I guess this is the case for any users creating
community cookbooks and testing via travis.  Opinions welcome.

Thanks,
Jay