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.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).
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 ?
Archive powered by MHonArc 2.6.16.