When testing on a filesystem used for a long time or built on a small
sized partition, the actual file order may be different from the
expected file order as below:
1) Failure:
inspec keyword::inspec.profile.files#test_0002_lists all profile files when calling #files [/work/git/inspec/test/unit/dsl/other_keywords_test.rb:50]:
--- expected
+++ actual
@@ -1 +1 @@
-["a_sub_dir/sub_items.conf", "items.conf"]
+["items.conf", "a_sub_dir/sub_items.conf"]
2) Failure:
SourceReaders::InspecReader::with a valid profile#test_0005_retrieves all extra files [/work/git/inspec/test/unit/source_readers/inspec_test.rb:39]:
--- expected
+++ actual
@@ -1 +1 @@
-["files/a_sub_dir/sub_items.conf", "files/items.conf"]
+["files/items.conf", "files/a_sub_dir/sub_items.conf"]
Signed-off-by: ERAMOTO Masaya <eramoto.masaya@jp.fujitsu.com>
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>
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>
