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>
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>
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>
Previously, all resources were loaded into a single resource registry.
Now, each profile context has a resource registry, when a profile's
library is loaded into the profile context, we update the
profile-context-specific resource registry. This local registry is
then used to populate the execution context that the rules are
evaluated in.
Signed-off-by: Steven Danna <steve@chef.io>
The goal of this change is to provide an isolated view of the available
profiles when the user calls the include_controls or require_controls
APIs. Namely,
- A profile should only be able to reference profiles that are part of
its transitive dependency tree. That is, if the dependency tree for a
profile looks like the following:
A
|- B --> C
|
|- D --> E
Then profile B should only be able to see profile C and fail if it
tries to reference A, D, or E.
- The same profile should be include-able at different versions from
different parts of the tree without conflict. That is, if the
dependency tree for a profile looks like the following:
A
|- B --> C@1.0
|
|- D --> C@2.0
Then profile B should see the 1.0 version of C and profile D should
see the 2.0 profile C with respect to the included controls.
To achieve these goals we:
- Ensure that we construct ProfileContext objects with respect to the
correct dependencies in Inspec::DSL.
- Provide a method of accessing all transitively defined rules on a
ProfileContext without pushing all of the rules onto the same global
namespace.
This does not yet handle attributes or libraries.
