Create the `slave.jar` in a slave’s JENKINS_HOME
Support a checksum attribute for `winsw.exe` download
Support setting the `PATH` on Windows slave
Add .NET 4.0 compat fix for `winsw`
Update Jenkins service check to use `WIN32OLE`

A dependency on the `ruby-wmi` gem has been removed so the
`WMI::Win32_Service` no longer exists. This fixes an issue uncovered in:

opscode-cookbooks/windows#106
opscode-cookbooks/chef-client#175
Actually use the `service_name` attribute to name Windows service
Restart services when `slave.jar` is updated

A `slave.jar` update usually occurs on Jenkins master upgrades! If your
master and slave out of version sync, bad things can happen.
Properly quote executor file paths cause $WINDOWS
Properly escape backslashes in generated Groovy code

This will prevent Groovy errors like:

  org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
  Script1.groovy: 1: unexpected char: '\' @ line 1, column 4.
     "C:\jenkins"
Allow `jenkins_slave` to be used as a standalone resource

This is useful in situations where you want create a slave instance on
the Jenkin’s master but still control creation of the underlying service
resources.
Merge pull request #283 from opscode-cookbooks/schisamo/fixes

Assorted Fixes
Update for ServerSpec 2
Make custom matchers available to ServerSpec tests
Fix ChefSpec 4.1.x deprecation warnings
Use credentials object directly when creating SSHLauncher

We found a weird bug where the SSHLauncher(String, int, String, String,
String, String) constructor was setting the credentials to null instead
of a valid (already created) credentials.

The SSHLauncher constructor being used is:
https://github.com/jenkinsci/ssh-slaves-plugin/blob/ssh-slaves-1.6/src/main/java/hudson/plugins/sshslaves/SSHLauncher.java#L249

To handle these broken slaves, I had to add a null check for credentials
in the returned JSON.
Update integration tests to use latest Jenkins LTS release
Update integration tests to use Chef 12.0.0.rc.1
Replace service notifications with runit_service.

At the 1.0 release, the runit cookbook replaced it's definition with a
resource and provider that extend the built-in chef service resource.
However, it provided a wrapper for users, that created a generic service
resource. This generic resource also ignored settings passed (like the
timeout setting in runit). This commit replaces all of the instances of
`notifies :foo, 'service[jenkins]'` with `notifies :foo, 'runit_service[jenkins]'`.
add attribute for Jenkins user system account

Originally introduced in the Debian packaging system for jenkins in 2008
[1], the packagers determined that the user (hudson) at the time should
be a `system` user, meaning that there are no password aging information
or home directories automatically created, as well as be created in the
SYS_UID_* numeric range.

When introducing the `war` style installation [2], the user/group are
created as the next available uid/gid in UID_MIN/GID_MIN (see
/etc/login.defs), which collides with any users created after that may
be expecting specific UIDs.

Existing systems will be unaffected, as the `user` resource does not
modify the already-created user, rather only new systems using the war
method will have their `jenkins` daemon user created as a system user,
like the package does already.

[1]: https://issues.jenkins-ci.org/browse/JENKINS-1959
[2]: https://github.com/opscode-cookbooks/jenkins/commit/3e29e2f9e0d693b5ffa8d8a23f68440119a3c44c
Comment about UUID for credential