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>
This is a regression introduced by the changes from string to symbol
keys in v0.34.0. It seems that our test cookbook that had a nested
dependency example wasn't actually wired up to run.
This adds a basic functional test and corrects the typo.
Signed-off-by: Steven Danna <steve@chef.io>
This adds a new git fetcher. In doing so, it also refactors how the
fetchers work a bit to better support fetchers that need to resolve
user-provided sources to fully specified sources appropriate for a
lockfile.
Signed-off-by: Steven Danna <steve@chef.io>
A few minor issues were causing 3 functional test failures on OS X.
These were not program errors but where rather the result of the
profiles under test assuming a linux environment.
Since many of the developers who will work on this project in the future
will be running OS X, let's ensure they can run the functional tests
easily.
Signed-off-by: Steven Danna <steve@chef.io>
(1) The field is not yet optimal, the calculations are great!
(2) Changing this field should go together with all other breaking json changes, especially if https://github.com/chef/inspec/pull/811 results in a change.
Mixing types in an array without specifying what these fields point to is not just confusing, but also causes issues with endpoints that may consume this data and dont process mixed types. We strive to have a stable api for 1.0 and this is a sin that was left after the major overhaul. Time to fix it.
this happens when the profile is run (exec) and also interpreted (via profile.params). It will load 2 profile context calls (both via Runner) which in turn gets 2 rounds of interpreter+runner executions. This is an issue with auto-generated IDs, due to their random component, which changes in this case
Full rewrite of all formatters. Create a minimal JSON, a full JSON, and a fallback RSpec formatter. The latter is only needed for corner cases and should not really be used. The former 2 are for (1) running `inspec json` followed by `inspec exec` (`--format json`) and (2) running just `inspec exec --format fulljson`.
Instead of just removing all tests because of OS support, supports now acts by adding all tests to the execution context, but doesnt actually execute them. Instead tests are set to skip before they get to the actual execution context
