Commit graph

4 commits

Author SHA1 Message Date
James Stocks
350c0bfe8f Handle waiver expiration dates being YAML strings
This is technically incorrect YAML, but if you transcode YAML between several tools you may end up with a date/time value being an explicit string.
It would be helpful if InSpec supported any string value that easily translates to a Time.

Signed-off-by: James Stocks <jstocks@chef.io>
2020-05-20 15:00:43 +01:00
James Stocks
35e36ad40a Allow for waiver time as well as date
Fixes #5037

The YAML parser may parse a waiver timestamp as a Time rather than a Date. Even when the user doesn't care about time, they may be using a tool that outputs YAML with trailing zeroes for hour, minutes, seconds etc.

Signed-off-by: James Stocks <jstocks@chef.io>
2020-05-20 14:59:07 +01:00
Nick Schwaderer
a1129f9efc Allows input and control to have the same name
In https://github.com/inspec/inspec/issues/4936 the issue was reported that naming an input the same as a control caused an unexpected failure.

In that particular case, the naming was a result of a pre-waivers workaround which is no longer necessary, but ultimately a breakage of that name clash is an unexpected occurrance.

Due to how inputs are named and registered, `__apply_waivers` thinks that an object is a waiver that is not a waiver and tries to process it. On the micro level, it breaks when trying to pass a variable to a string as if it were a Hash.

It is imperative that we preserve 100% of the current featureset, pass our tests, and fix this edge case along with new test coverage for the failure.

This PR updates the code to do a slightly more elegant and small ‘waiver check’ to stop the namespace clash from breaking our code.

Signed-off-by: Nick Schwaderer <nschwaderer@chef.io>
2020-05-05 10:00:19 +01:00
Ryan Davis
db8e6e7415 Moved test/unit/mock/* to test/fixtures
Signed-off-by: Ryan Davis <zenspider@chef.io>
2019-11-08 16:29:03 -08:00