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
On Fri, Oct 10, 2014 at 8:22 AM, Paul C firstname.lastname@example.org 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
On Fri, Oct 10, 2014 at 9:53 AM, Ranjib Dey email@example.com 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
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.
On Fri, Oct 10, 2014 at 5:43 AM, JayP firstname.lastname@example.org wrote:
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
your CI Server agents as well to do the testing of your cookbooks? All
repositories have a Gemfile which have some duplicate gems so it
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
chef so that would mean the chef-client that comes with ChefDK would be
provision the host with other things such as vagrant, virtualbox, rbenv,
If folks think it is low risk to use the chef gem for CI instead of
think I prefer that route as it makes it easier to upgrade itself etc.
are folks thoughts on this? I guess this is the case for any users
community cookbooks and testing via travis. Opinions welcome.