If you’re like me and for various reasons (we’ll not discuss) the physical hardware you have access to right now must run Windows, you might think you’re out of luck as far as getting Jenkins running Test-Kitchen jobs as Joshua Timberman shows in Test Kitchen and Jenkins1. But there’s hope if you have patience. I’ll show how I got it working, and I’m looking forward to ideas from you on how to develop better solutions to some of the kludges. There’s not much original material here, but instead of mentioning just my piece of things and linking you coldly to 2 other places for the rest of the info, I figured I would write up as much of the whole experience as I felt up to.
Prerequisites
Windows Add-Ons
It is assumed that you have the following installed. If not, do so.
- Ruby 1.9.3 from rubyinstallers.org
- Git 1.8.x for Windows from git-scm.com/download. All commands shown below are run under a “Git Bash” session and not Windows’ cmd.exe! unless explicitly stated as such.
- Jenkins
Ruby Gems
At this point, you should open a Git-Bash shell and ensure that which gem
indicates the one found in the Ruby 1.9.3 install you did previously. For me, that was /c/Ruby193/bin/gem
.
Start with: gem install bundler
Then, in the directory containing the cookbook you want to test, create a Gemfile
with the following contents:
source 'https://rubygems.org' gem 'test-kitchen', '~> 1.0.0.alpha.7'
Run: bundle install
Run: kitchen init
Run: bundle install
(yes, again)
Run: kitchen help
to ensure Test Kitchen can at least run.
Edit .kitchen.yml
to look like the following (configure later how you want):
--- driver_plugin: vagrant driver_config: require_chef_omnibus: true platforms: - name: ubuntu-12.04 driver_config: box: opscode-ubuntu-12.04 box_url: https://opscode-vm.s3.amazonaws.com/vagrant/opscode_ubuntu-12.04_provisionerless.box suites: - name: default run_list: [] attributes: {}
At this point you should be able to run kitchen test
and see something success-like.
Jenkins
The Windows installer for Jenkins is nice in that it configures Jenkins to run as a Windows service. So go get and install that from jenkins-ci.org/windows/latest. Once installed, you should be able to hit http://localhost:8080
and see the Jenkins web UI.
Use the web UI to install the “Git” plugin.
Configure a new Jenkins job. For my case, it looked like the following.
- Source Code Management, Git Repositories, Repository URL:
git://github.com/jblaine/resolver.git
(use the Git read-only URL to the repo, not SSH, or you’ll have to mess with copying your SSH stuff similar to the problem section below regarding Vagrant) - Build Triggers, Poll SCM, Schedule:
H 9-16/2 * * 1-5
- Excute a Windows Batch Command:
kitchen test
And click “Build now” at left to start the troubleshooting process below.
Problem: Jenkins can’t find Git
If you see in your job’s console output that Jenkins is not able to find Git, set the full path to the executable binary (regardless of the setting being called “Installation Directory”) as I did. This is the only thing that worked for me after trying a few other things found on the net.
Oh, and you apparently have to use the old 8dot3 naming. No spaces allowed. What is this, 1999?
Manage Jenkins, Configure System, Git, Git Installations, Installation Directory: C:\Progra~2\Git\cmd\git.exe
Problem: Vagrant can’t import Boxes
Perhaps this is the next roadblock you hit:
... STDOUT: Bringing machine 'default' up with 'virtualbox' provider... [default] Box 'opscode-ubuntu-12.04' was not found. Fetching box from specified URL for the provider 'virtualbox'. Note that if the URL does not have a box for this provider, you should interrupt Vagrant now and add the box yourself. Otherwise Vagrant will attempt to download the full box prior to discovering this error. Downloading or copying the box... ... Successfully added box 'opscode-ubuntu-12.04' with provider 'virtualbox'! [default] Importing base box 'opscode-ubuntu-12.04'... STDERR: There was an error while executing `VBoxManage`, a CLI used by Vagrant for controlling VirtualBox. The command and stderr is shown below. Command: ["import", "C:/WINDOWS/system32/config/systemprofile/.vagrant.d/boxes/opscode-ubuntu-12.04/virtualbox/box.ovf"] Stderr: 0%... Progress state: VBOX_E_FILE_ERROR VBoxManage.exe: error: Appliance read failed VBoxManage.exe: error: Could not read OVF file 'box.ovf' (VERR_PATH_NOT_FOUND) VBoxManage.exe: error: Details: code VBOX_E_FILE_ERROR (0x80bb0004), component Appliance, interface IAppliance VBoxManage.exe: error: Context: "int __cdecl handleImportAppliance(struct HandlerArg *)" at line 306 of file VBoxManageAppliance.cpp ---- End output of vagrant up --no-provision ---- Ran vagrant up --no-provision returned 1 >>>>>> ---------------------- >>>>>> Please see .kitchen/logs/kitchen.log for more details Build step 'Execute Windows batch command' marked build as failure Finished: FAILURE
What’s telling here is that Vagrant is looking for boxes in C:\Windows\System32
and not C:\Windows\SysWOW64
. My wildly speculative guess is that this is because Vagrant is a 32-bit application and somehow this ties it to the different directory, even though the Jenkins service is tied to C:\Windows\SysWOW64
by nature of the LocalSystem
account.
I’m pretty Windows-guts clueless as you can see. Any explanation you can share here, please do in the comments.
At any rate, we persist. Using a cmd.exe
that is run as Administrator, we look around:
C:\>dir C:\Windows\System32\config\systemprofile Volume in drive C has no label. Volume Serial Number is 9424-87E5 Directory of C:\Windows\System32\config\systemprofile 06/11/2013 11:16 AM <DIR> .vagrant.d 06/11/2013 11:19 AM <DIR> .VirtualBox 10/27/2012 12:17 PM <DIR> AppData 10/27/2012 12:17 PM 262,144 ntuser.dat 06/11/2013 11:19 AM <DIR> VirtualBox VMs 1 File(s) 262,144 bytes 6 Dir(s) 279,382,310,912 bytes free C:\>dir C:\Windows\System32\config\systemprofile\.VirtualBox Volume in drive C has no label. Volume Serial Number is 9424-87E5 Directory of C:\Windows\System32\config\systemprofile\.VirtualBox 06/11/2013 11:19 AM <DIR> . 06/11/2013 11:19 AM <DIR> .. 06/11/2013 11:19 AM 32,520 VBoxSVC.log 06/11/2013 10:54 AM 1,114 VBoxSVC.log.1 06/11/2013 10:47 AM 886 VBoxSVC.log.2 06/11/2013 11:19 AM 1,066 VirtualBox.xml 06/11/2013 11:18 AM 1,285 VirtualBox.xml-prev 5 File(s) 36,871 bytes 2 Dir(s) 279,382,302,720 bytes free C:\>
Okay, so some VirtualBox stuff happened in C:\Windows\System32
. But we can see that Vagrant has set up shop in C:\Windows\SysWOW64
:
C:\Users\jblaine>dir C:\Windows\SysWOW64\config\systemprofile\.vagrant.d\boxes Volume in drive C has no label. Volume Serial Number is 9424-87E5 Directory of C:\Windows\SysWOW64\config\systemprofile\.vagrant.d\boxes 06/11/2013 10:54 AM <DIR> . 06/11/2013 10:54 AM <DIR> .. 06/11/2013 10:54 AM <DIR> opscode-ubuntu-12.04 0 File(s) 0 bytes 3 Dir(s) 279,808,155,648 bytes free C:\Users\jblaine>
Welp, I’m unaware of any environment variable that would allow me to tell Vagrant to use C:\Windows\SysWOW64\config\systemprofile\.vagrant.d
, so I just copied everything over to C:\Windows\System32\config\systemprofile\.vagrant.d
.
Success!
Rerunning the Jenkins build, you should now succeed, and at this point you would want to go back into your cookbook’s .kitchen.yml
file to actually establish some tests to run in the suites
section.
... C:\Program Files (x86)\Jenkins\workspace\test-resolver>kitchen test -----> Starting Kitchen (v1.0.0.alpha.7) ... [default] Importing base box 'opscode-ubuntu-12.04'... ... -----> Converging-----> Installing Chef Omnibus (true) ... [2013-06-11T15:19:39+00:00] INFO: *** Chef 11.4.4 *** ... [2013-06-11T15:19:39+00:00] INFO: Chef Run complete in 0.009065059 seconds ... -----> Kitchen is finished. (1m29.52s) Finished: SUCCESS
References
- Test Kitchen Wiki
- https://github.com/opscode/test-kitchen/wiki/Getting-Started
- Test Kitchen and Jenkins
- http://jtimberman.housepub.org/blog/2013/05/08/test-kitchen-and-jenkins
- Jenkins Git Plugin (wiki page)
- https://wiki.jenkins-ci.org/display/JENKINS/Git+Plugin#GitPlugin-
You could use mklink to symlink the files together
mklink link target
ie:
mklink “C:WindowsSystem32configsystemprofile.vagrant.d” “C:WindowsSysWOW64configsystemprofile.vagrant.d”
Makes a link in system32 pointing to the file in syswow64, like normal unix symlinks
VAGRANT_HOME