Guess what? We have a couple of pre-release gems cut today for Test Kitchen, specifically:

test-kitchen 1.4.0.beta.2 (beta.1 cut yesterday)

kitchen-vagrant 0.17.beta.2 (beta.1 cut yesterday)

Here’s my ask for anyone with time/interest/ability in the next day or 2:

Where ever you use Test Kitchen, give this pair of releases a try. If you don’t care about the Vagrant Driver, then just use the Test Kitchen pre-release. Use it exactly as you would any previous stable release, don’t change anything.

—END tl;dr—

It’s extremely important that this release doesn’t break existing projects, Drivers, and/or Provisioners in the wild. If you find issues, please let myself or Tyler Ball know and file an issue if you can. Linking to a reproducible project and kitchen diagnose —all output (scrubbed for credentials first) is such a big help, you have no idea.

Installing

If you have a Ruby workflow with RubyGems and/or Bundler this won’t be too much work:

chefdk-update-app - A little help when you want to update an appbundled project inside ChefDK

To update the kitchen-vagrant gem, simply:

chef gem install kitchen-vagrant --pre --minimal-deps

Windows!

Note that this release has the much-fabled “Windows guest support” (insert “oooo, ahhhh” here). How do you get started? At the moment getting Vagrant base box images of Windows is still a big pain, but if you have access to one, here are the versions that should “just work”:

Windows with Kitchen::Vagrant

Any Vagrant base box should have vm.communicator = “winrm” and vm.guest = “windows” set by default, otherwise vagrant up will not be able to correctly boot the VM. Note that there are some Windows base boxes out there with vm.communicator = “ssh” set, so plan accordingly.

Assuming you have a Vagrant base box called “windows-2012r2”, you can use a .kitchen.yml similar to:

—
driver:
name: vagrant

platforms:

name: windows-2012r2

suites:

name: default

Note that with the updates in kitchen-vagrant you don’t need to set/override a :box, :box_url, :communicator, :guest, :port, :username, or :password. Sane defaults should apply.

For anyone who has tried the windows-guest-support branch, you may have seen extra transport configuration like this:

—
driver:
name: vagrant

platforms:

name: windows-2012r2
transport:
name: winrm

suites:

name: default

This is what Test Kitchen’s going to give you by default for any platform name starting with /^win/ (case insensitive) so add it, or don’t, it should work either way. If you don’t believe me, run kitchen diagnose against both and note the difference

Finally, if you use certain Vagrant providers or use private networks in your setup, kitchen-vagrant is not currently able to determine your WinRM port. I’m hoping to fix this with a Vagrant plugin which kitchen-vagrant can use to return it’s WinRM and RDP hostname and port.

Further Reading

You can check out the CHANGELOG for more details/links regarding beta.1 and beta.2:

Guess what? We have a couple of pre-release gems cut today for Test Kitchen, specifically:

test-kitchen 1.4.0.beta.2 (beta.1 cut yesterday)

kitchen-vagrant 0.17.beta.2 (beta.1 cut yesterday)

Here’s my ask for anyone with time/interest/ability in the next day or 2:

Where ever you use Test Kitchen, give this pair of releases a try. If you don’t care about the Vagrant Driver, then just use the Test Kitchen pre-release. Use it exactly as you would any previous stable release, don’t change anything.

—END tl;dr—

It’s extremely important that this release doesn’t break existing projects, Drivers, and/or Provisioners in the wild. If you find issues, please let myself or Tyler Ball know and file an issue if you can. Linking to a reproducible project and kitchen diagnose —all output (scrubbed for credentials first) is such a big help, you have no idea.

Installing

If you have a Ruby workflow with RubyGems and/or Bundler this won’t be too much work:

Windows!

Note that this release has the much-fabled “Windows guest support” (insert “oooo, ahhhh” here). How do you get started? At the moment getting Vagrant base box images of Windows is still a big pain, but if you have access to one, here are the versions that should “just work”:

Windows with Kitchen::Vagrant

Any Vagrant base box should have vm.communicator = “winrm” and vm.guest = “windows” set by default, otherwise vagrant up will not be able to correctly boot the VM. Note that there are some Windows base boxes out there with vm.communicator = “ssh” set, so plan accordingly.

Assuming you have a Vagrant base box called “windows-2012r2”, you can use a .kitchen.yml similar to:

—
driver:
name: vagrant

platforms:

name: windows-2012r2

suites:

name: default

Note that with the updates in kitchen-vagrant you don’t need to set/override a :box, :box_url, :communicator, :guest, :port, :username, or :password. Sane defaults should apply.

For anyone who has tried the windows-guest-support branch, you may have seen extra transport configuration like this:

—
driver:
name: vagrant

platforms:

name: windows-2012r2
transport:
name: winrm

suites:

name: default

This is what Test Kitchen’s going to give you by default for any platform name starting with /^win/ (case insensitive) so add it, or don’t, it should work either way. If you don’t believe me, run kitchen diagnose against both and note the difference

Finally, if you use certain Vagrant providers or use private networks in your setup, kitchen-vagrant is not currently able to determine your WinRM port. I’m hoping to fix this with a Vagrant plugin which kitchen-vagrant can use to return it’s WinRM and RDP hostname and port.

Further Reading

You can check out the CHANGELOG for more details/links regarding beta.1 and beta.2: