* Support PAX-formatted tar files, standardize file lists
When a tar file is generated in PAX format, the files have an additional
relative path prefix added to them. For example, instead of:
inspec.yml
... the file is listed as:
./inspec.yml
And the source reader plugin looks only for a "inspec.yml" file to
determine the profile format.
This change addresses this issue by normalizing the file paths in the
TarReader and accounting for the additional "./" prefix that may exist
whenever the tar file is walked looking for a file to read its content.
Signed-off-by: Adam Leff <adam@leff.co>
* Remove pax from unit test, will move to functional
Signed-off-by: Adam Leff <adam@leff.co>
* Add function test for the pax header tar file
Signed-off-by: Adam Leff <adam@leff.co>
* bugfix: empty file strings from archive readers
Empty files in archives are sometimes possible (we just ran into this with TGZ), but is never a valid file to extract. So remove it and discount it altogether. Changed structure to support testing of these global calls.
Signed-off-by: Dominik Richter <dominik.richter@gmail.com>
* lint and rebuild
Signed-off-by: Dominik Richter <dominik.richter@gmail.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>
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>
