Due to limitations in Thor it is not possible to set an argument to be both optional and its value to be mandatory. E.g. the user supplying the --password argument is optional and not always required, but whenever it is used, it requires a value. Handle options that were defined with mandatory values in a way that fails with an `ArgumentError` if the value is missing, i.e.:
```
> inspec exec examples/profile --password
ArgumentError: Please provide a value for --password. For example: --password=hello.
```
It works without `--password` or with `--password=arg`. Also handled for `--sudo-password`.
Fixes: https://github.com/chef/inspec/issues/1901
As suggested: https://github.com/chef/inspec/pull/1904
Signed-off-by: Dominik Richter <dominik.richter@gmail.com>
Generated duplicate messages due to the way that examples are aggregated in RSpec. Make sure we never show any duplicate test result messages, as they offer not value to any user.
Signed-off-by: Dominik Richter <dominik.richter@gmail.com>
The CLI formatter is not currently honoring the --no-color flag
when outputting CLI output. This change cleans up how we format
with color and properly support the flag for use cases where
color-encoding characters make the output difficult to use
(i.e. when someone redirects CLI output to a text file for
sharing with others).
Signed-off-by: Adam Leff <adam@leff.co>
Running `inspec exec` with --sudo locally produces unintended results
given that we cannot escalate local Ruby methods after we're already
running. --sudo is meant to only be used with remote targets. We do
not currently enforce that.
This change will print an error for the user if they attempt to use
--sudo with a local exec and exit non-zero.
Signed-off-by: Adam Leff <adam@leff.co>
A new `help matchers` command will provide helpful examples on a few
of the standard matchers: be, cmp, include, etc.
I also cleaned up the formatting of the resources list and provided
better feedback if a user requests help for an unknown resource.
Resolves#1684
Signed-off-by: Adam Leff <adam@leff.co>
In #1454, we welcomed a newly-revamped JUnit formatter which has
a dependency on Nokogiri. Unfortunately, this had led us to problems
getting InSpec included in Chef omnibus builds (see chef/chef#5937)
because Chef is using Ruby 2.4.1 and the Nokogiri maintainers have
not yet released a windows binary gem that supports Ruby 2.4.x.
This has led to breaking builds in Chef's CI platform and would
block the acceptance of chef/chef#5937.
This change replaces Nokogiri use with REXML instead. While REXML
can be slower than Nokogiri, it does not require native extensions
and is supported on all Chef platforms.
Signed-off-by: Adam Leff <adam@leff.co>
The CLI output for the vendoring of profiles has been updated slightly
to be more clear, and the functional tests have been modified to match
as well.
Signed-off-by: Adam Leff <adam@leff.co>
When in inspec shell, you need to type the `help` command to find out info
about your target system. This info would be super helpful right out of the
gate so users have confidence that they're targeting the correct system.
The target info is still available via the `help` command as it always has
been, as well.
Signed-off-by: Adam Leff <adam@leff.co>
When running InSpec with multiple profiles, and two or more of the profiles
are read in using the "Flat" SourceReader (i.e. they are not actual profiles
with a metadata file like inspec.yml, but rather just a folder containing
.rb files with controls and tests in them), InSpec would throw a NilClass
error when building the necessary objects for the formatter.
The cause was in `#profile_contains_example` in the formatter code which
checks to see if the profile name is the same as the profile_id in the given
example. However, if both of those were nil, it would potentially match the
wrong Flat-read profile.
This change fixes this in two ways: refusing to match if the profile name
or example profile ID is nil, and adding a default name to a profile if
it doesn't have a title or name. This will solve the matching issue and also
clean up the formatter output so users can more easily tell what tests
are from which profile/path.
Signed-off-by: Adam Leff <adam@leff.co>
* Fixes an issue when specifying no profile
* Fixes an issue when displaying a profile that has included/required profiels
* Fixes an issue when specifying profiles with only metadata
* Fixes formatting for spacing to ensure it adheres to previous alignment
* Fixes issue with the Control object and the rolling up of failed
and skipped examples.
Signed-off-by: Franklin Webber <franklin@chef.io>
Previous, require_controls was including all controls from the named
profile, despite the documented behavior being that it only includes
controls explicitly pulled in by the user. The cause was two-fold:
1) A previous refactor meant that we weren't removing the rule from the
correct context, and
2) We weren't descending down the dependency tree when filtering rules.
This commit fixes the require_controls DSL method and adds a test to
help prevent future regressions.
Signed-off-by: Steven Danna <steve@chef.io>
This commit threads through some state related to whether or not a
profile is "local", that is whether it is a directory on disk. If it
is, we then write out the lockfile to disk.
Signed-off-by: Steven Danna <steve@chef.io>
All resources from deps are added into the control_eval_context used by
the current profile. However, if there is a name conflict, the last
loaded resource wins. The new `require_resource` dsl method allows the
user to do the following:
require_resource(profile: 'profile_name',
resource: 'other',
as: 'renamed')
describe renamed do
...
end
Signed-off-by: Steven Danna <steve@chef.io>
