macOS 11 Big Sur will be released later this year. Current beta versions
return 10.16 as the version, but the product name has changed from 'Mac
OS X' to 'macOS'. Train probably needs to be modified to deprecate
'mac_os_x' as a platform in favor of 'macos' but that would be a
significant downstream change. Train does fall back to 'darwin' on macOS
10.16, so by adding darwin to the list of platform names for the service
resource we are able to work around this for the moment.
This is the only location where mac_os_x is currently being used in
InSpec. Because we're in a case statement on platform rather than the
more generic platform family, we can't simply remove mac_os_x in favor
of darwin.
Signed-off-by: Bryan McLellan <btm@loftninjas.org>
We have 72 `skip_windows` that need addressing. This PR removes
confirmed instances where the tests now work on windows. It also marks
tests with a comment where they are confirmed to still break. Unmarked
instances still need review.
It also updates the `skip_windows` expiration date.
72 `skip_windows` needing resolution OR alternative documentation upon investigation
Signed-off-by: Nick Schwaderer <nschwaderer@chef.io>
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>
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>
I removed the skip to see what would break, and on my Windows laptop
these tests pass OK. The TODO didn't explain what wasn't applicable to
Windows, so I'm just going to remove it.
Signed-off-by: James Stocks <jstocks@chef.io>
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>
