When attempting to parse the profile out of the target URL, we
were not raising an exception if we failed to do so. Such a situation
could arise if a user's inspec config.json is incorrect either due to
manual editing or failure to re-login after an upgrade past Automate
0.8.0.
This change provides a clear exception if this occurs and also adds
tests for the compliance_profile_name method.
Signed-off-by: Adam Leff <adam@leff.co>
The gem resource used to determine if a gem is installed based on the exit
status of the `gem` command, however that command will return zero
if the package was found or not. This patch checks to ensure that the
`gem list` command actually includes the gem name or is empty to
determine if the gem is in fact installed.
If the gem command returns something other than a `0` exit code, then
it'll skip the resource.
Signed-off-by: Keith Walters <keith.walters@cattywamp.us>
Inspired by #1640, this change cleans up the logic used when
reading in secrets files, provides clearer warnings when the
secrets files can't be parsed, and adds tests for those methods.
Signed-off-by: Adam Leff <adam@leff.co>
RubyGems on windows comes with a batch file that wraps the `gem` command
so it executes correctly. This change uses that batch file for windows
for our `gem` resource, and also properly handles when we receive no output
from the command.
Signed-off-by: Adam Leff <adam@leff.co>
Two new commands have been created:
* inspec habitat profile create /path/to/profile
* inspec habitat profile upload /path/to/profile
The `create` command creates a Habitat artifact that contains the contents
of the Habitat profile found at the provided path. This will be used later
in some Habitat + InSpec integrations.
The `upload` command does the same create process but then uploads the
resulting artifact to the Habitat Depot.
Signed-off-by: Adam Leff <adam@leff.co>
The following new resources have been added; however, they
presently only support FreeBSD and similar.
* `zfs_dataset`: tests if a named ZFS dataset is present
and/or has certain properties.
* `zfs_pool`: tests if a named ZFS pool is present and/or
has certain properties.
Additionally, the `mount` resource has been reworked to
include support for FreeBSD; while the existing class
was renamed to LinuxMountParser.
Unit-tests were added for all of the above.
Signed-off-by: Joseph Benden <joe@benden.us>
The crontab resource parses a particular user's crontab file into
individual entries and allows the user to assert information about
each entry as needed.
Signed-off-by: Adam Leff <adam@leff.co>
This pull request adds a packages resource so that we can check for pattern matches against all the packages on a system. This initially implements only dpkg support for debian-based platforms so we can cover this use case:
```ruby
describe packages(/^xserver-xorg.*/) do
its("list") { should be_empty }
end
```
This uses FilterTable so we can supply additional queries, too.
```ruby
describe packages(/vi.+/).where { status != 'installed' } do
its('statuses') { should be_empty }
end
```
Users can specify the name as a string or a regular expression. If it is a string, we will escape it and convert it to a regular expression to use in matching against the full returned list of packages. If it is a regular expression, we take that as is and use it to filter the results.
While some package management systems such as `dpkg` can take a shell glob argument to filter their results, we eschew this and require a regular expression to match multiple package names because we will need this to work across other platforms in the future. This means that the following:
```ruby
packages("vim")
```
Will return *all* the "vim" packages on the system. The `packages` resource will take `"vim"`, turn it into `/vim/`, and greedily match anything with "vim" in the name. To match only a single package named `vim`, it needs to be an anchored regular expression.
```ruby
packages(/^vim$/)
```
Signed-off-by: Joshua Timberman <joshua@chef.io>
Use entries instead of list
Added a few more tests and non installed package in output
Signed-off-by: Alex Pop <apop@chef.io>
fix lint
Signed-off-by: Alex Pop <apop@chef.io>
Signed-off-by: Joshua Timberman <joshua@chef.io>
Before this change, simplecov was reporting
1864 / 5198 LOC (35.86%) covered
After this change it is reporting
4131 / 5275 LOC (78.31%) covered.
Keeping the require at the top of the file ensure that simplecov is
loaded before any of our application code.
The goal of these changes is to ensure that the libraries from
dependencies are loaded even if their controls are never included. To
facilitate this, we break up the loading into seperate steps, and move
the loading code into the Profile which has acceess to the dependency
information.
Signed-off-by: Steven Danna <steve@chef.io>
Many of the resources are named as a top-level class with a fairly generic class name, such as "OS". This causes an issue specifically with kitchen-google which depends on a gem which depends on the "os" gem which itself defines an OS class with a different superclass. This prevents users from using TK, Google Compute, and Inspec without this fix.
Some mocked commands had their digest changed as well due to the new indentation, specifically in the User and RegistryKey classes.
I strongly recommend viewing this diff with `git diff --ignore-space-change`
to see the *real* changes. :)
Currently, #readable?, #writeable?, and #executable? will incorrectly
return true if the file does not exist.
In addition, I took the opportunity to refactor the File resource to
make it easier to write unit tests and supplied a full unit test
suite for this resource.
before, the resource would throw an exception when include_files
returned nil (i.e., [].flatten!)
added basic unit tests capturing the include_files behaviour
