We have released Test Kitchen version 0.7.0. This release brings some important new features and improvements we’d like to tell you about in more detail.
OpenStack Runner
The first new feature is an Openstack runner. We have an OpenStack build cluster for our Jenkins jobs, and we’ve started adding cookbook’s in test kitchen to Jenkins. We previously used a Vagrant/VirtualBox based setup that was working okay, but it was running on OpenStack instances already anyway. To use the OpenStack runner, the configuration has to be added to the Kitchenfile.
For example:
[ruby]
openstack do
auth_url "http://openstack-auth-host.example.com:5000/v2.0/tokens"
username "my-openstack-user"
password "super-duper-secret-password"
tenant "cookbook-tests"
end
platform "centos" do
version "5.8" do
image_id "the image ID to use for centos 5.8"
flavor_id "2"
keyname "test-kitchen-ssh-key"
instance_name "centos-5.8-test-kitchen"
install_chef true
install_chef_cmd "wget -O – http://www.opscode.com/chef/install.sh | sudo bash"
ssh_user "root"
ssh_key "/home/test-kitchen/.ssh/openstack-ssh-private-key"
end
end
[/ruby]
For Opscode’s public cookbooks, we’re not adding the OpenStack details to the public Kitchenfiles, but we do have a script in the Jenkins jobs that concatenates that into the Kitchenfile when they’re run.
Cheffile Updates
The next important change is that the Cheffile included with Test Kitchen no longer specifies the apt, yum, build-essential, git and rvm cookbooks. The existence of these cookbooks in the Cheffile caused “Cheffile and Cheffile.lock are out of sync” errors from Librarian when Test Kitchen assembled the cookbooks. Also, the versions of those cookbooks were pinned to releases from several months ago, which had their own bugs fixed. Test Kitchen has its own cookbook for doing the initial set up, and it already has unversioned dependencies on apt, git, and yum. Finally, in version 0.6.0, we removed the tight coupling with rvm, so we don’t need that cookbook. If you do want to run the integration tests in your project with RVM-installed Ruby, add the runtimes parameter to the project block in the Kitchenfile, and create a recipe in a project “test cookbook”. The recipe might look something like this:
[ruby]
node.set[‘rvm’][‘user_installs’] = [
{ ‘user’ => ‘vagrant’,
‘default_ruby’ => ‘ruby-1.9.3-p327’,
‘rubies’ => [‘1.9.3’]
}
]
node.set[‘rvm’][‘gems’] = {
"ruby-1.9.3-p327" => [
{ ‘name’ => ‘bundler’ }
]
}
include_recipe "rvm::user"
[/ruby]
This is taken from Opscode’s mixlib-shellout repository.
Bugs and Improvements
A bug was fixed in “kitchen init“, where the scaffolding for a cookbook project was not using the name attribute from the cookbook’s metadata. This was problematic when developing a cookbook in a directory, for example, named “cakes-cookbook”, but the metadata.rb had “name 'cakes'“.
Along with the “removing things that were associated with the RVM coupling,” the runtimes parameter with an empty array is no longer created in the Kitchenfile when doing kitchen init.
Finally, test-kitchen’s CLI now has a --version option, so you can tell what version you’re running.
Happy testing!
Bug
- [KITCHEN-23] – Generated Kitchenfile should honor cookbook name from metadata.rb
Improvement
- [KITCHEN-40] – If a cookbook project is included in the default Cheffile, librarian errors out
New Feature
- [KITCHEN-5] – Create Openstack Runner for test-kitchen
- [KITCHEN-34] – add –version to kitchen command to show test-kitchen's version
Task
- [KITCHEN-50] – don't exit with `1` if rcov is slipping, just warn
- [KITCHEN-51] – don't add runtimes [] line in cookbook scaffolding