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.
Jay, I am struggling with this problem as well. At first I started
converting everything in CI to use ChefDK but was having problems, so I'm
back looking for a suitable compromise that would allow for identical
results in both chefdk and CI environments. I'd love to hear how other
people are handling it.
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.
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
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.
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 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
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.
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.
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 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
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.
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" dey.ranjib@gmail.com 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.
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 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
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.
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).
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 ( GitHub - hartmantis/chef-dk-chef: A Chef cookbook for the Chef Development Kit) 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 lamont@opscode.com
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).
