Ruby's autoload feature is not threadsafe. We are hoping requiring the
docker plugin early will fix odd failures we have been seeing.
Signed-off-by: Steven Danna <steve@chef.io>
This allows the user to write:
describe port(22) do
it { should be_listening }
end
as well as
describe port('22') do
it { should be_listening }
end
without hitting an error.
Fixes#867
Signed-off-by: Steven Danna <steve@chef.io>
Using the `env` feature of the matrix builds is a little hack so that
one can quickly see what tests failed when looking at the build summary
page.
Signed-off-by: Steven Danna <steve@chef.io>
The output of `systemctl show SERVICENAME` can be misleading in the
case of non-native services (i.e. services configured via an init script
and integrated with systemd via a shim) or for more sophisticated unit
types.
For example, the UnitFileState of ntp is "bad":
> systemctl show ntp | grep UnitFileState
UnitFileState=bad
despite systemd reporting it as enabled:
> systemctl is-enabled ntp
ntp.service is not a native service, redirecting to
systemd-sysv-install
Executing /lib/systemd/systemd-sysv-install is-enabled ntp
enabled
Further, the old parsing code would have missed unit files in the
following states that are technically enabled:
enabled-runtime, indirect, generated, and transient
Using the `is-enabled` commands ensures that we report the same enabled
status that systemd reports, without having to update our own parsing in
the event that new unit states are added. Additionally, as shown above,
it handles the sysv compatibility helper.
Similarly, the is-active helper command ensures that we always report
the same active/not-active status as systemd would natively. For
instance, a quick reading of `src/systemctl/systemctl.c` in the systemd
source shows that systemctl reports units as active if they are in the
state `UNIT_ACTIVE` or `UNIT_RELOADING`.
Fixes#749
Signed-off-by: Steven Danna <steve@chef.io>
In many linux distributions a link to /proc/kcore is placed at
`/dev/core`. In TravisCI we see it at `/dev/kcore`. To avoid tests
failing for some developers locally, we support either location.
Without this, Travis often ends up running 2 CI jobs for updates to a
PR: 1 for the update to the PR, 1 for the push to the branch.
By adding this bit of config, travis will still run a job for any update
to a PR, but won't run a duplicate job for the push to the branch that
the PR is based off of. We use this in chef/chef and chef/chef-server
to reduce unnecessary use of TravisCI resource.
