Previously, libraries were loaded by instance_eval'ing them against
the same execution context used for control files. All resources were
registered against a single global registry when the `name` dsl method
was invoked. To obtain seperation of resources, we would mutate the
instance variable holding the globale registry and then change it back
at the end.
Now, we instance_eval library files inside an anonymous class. This
class has its own version of `Inspec.resource` that returns another
class with the resource DSL method and the profile-specific resource
registry.
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>
This is a minor refactor that I did while studying our loading code in
preparation for some deeper changes to how content loading works. The
overall goal of the refactor is to remove a few places where we were
passing a generic options hash and then only accessing a single item.
The comment hopefully clarifies to new developers in the code base how
content loading works at a high level.
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.
Also: Log to STDERR by default
NB: This will result in absolute paths being rendered to lock files. We
think that is OK for now since we are going to build some UX around
path-based dependencies and lock files. Namely, we are going to tell
people it is a bad idea.
Signed-off-by: Steven Danna <steve@chef.io>
Resolved an issue checking ports on windows
The previous version wasn't really checking if a port was accessible as we were only validating if the ping succeeded. Using TcpTestSucceeded to determine if the connection worked or not.
The Molinillo library is a good library for systems that need a
constraint solver that will solve dependency problems requiring a single
version of each named dependency.
In our case, the eventual goal is to allow libraries to have conflicting
transitive dependencies at runtime. Isolation will be provided by
restricting all calls within a given profile to scope which can only see
that profile's dependencies.
To facilitate working on the isolation feature, I've replaced the
Molinillo-based resolver with a minimal resolver which will allow us to
load multiple versions of the same library.
Since we will likely want a good amount of logging around this feature
in the future, I've added a Inspec::Log singleton-style class, replacing
the previous Inpsec::Log which appeared unused in the code base.
Signed-off-by: Steven Danna <steve@chef.io>
This adds a basic prototype of inspec.lock. When the lockfile exists on
disk, the dependencies tree is constructed using the information in the
lock file rather than using the resolver.
Signed-off-by: Steven Danna <steve@chef.io>
