If a profile has a data files directory that looks like this:
```
files/platforms/one/data.json
files/platforms/two/data.json
files/platforms/three/data.json
```
... the source reader will return the directories in the list of files but with
nil contents. This causes an issue when Inspec::Profile tries to create a sha256
checksum of the profile contents only to try to cast nil to a string when
building the null-delimited profile contents string.
Files that are empty will have an empty string as its contents, so it's safe to
assume that file entries with nil contents are actually a directory and have no
affect on the profile's checksum. Therefore, this change will eliminate any file
entries in responses from the source readers where the contents are nil.
Signed-off-by: Adam Leff <adam@leff.co>
Currently, if the inspec.yml for a profile is invalid (such as including
an improperly-defined multi-line string), InSpec will throw an exception
from the YAML parser that does not given a clear indication that the
issue was encountered while parsing the inspec.yml file.
This change introduces a better exception message to clue the user into
where the problem actually lies.
Signed-off-by: Adam Leff <adam@leff.co>
The inline docs for SourceReaders::InspecReader#new state that it takes
a SourceReader object for the target... but we're trying to create the
SourceReader object! It actually takes a FileProvider object that is
capabile of listing files for the given profile and reading them.
Signed-off-by: Adam Leff <adam@leff.co>
We already monkeypatch require so that it is redirected through the
require_loader. All of the tests pass with this removal. We might
cause some breakage with this removal that we aren't testing, but given
that we are mucking with `require` it seems preferable to have one
mechanism by which we do that and solve any bugs with that single path.
Signed-off-by: Steven Danna <steve@chef.io>
