These tests are being worked on, and there has been internal discussion
about the value of this bomb. I am not taking a stance on that at this
point. However, when we do hit a bomb that requires all repo PRs (
including community ) to do a rebase after we do a fixing PR.
To prevent this while our team resource is somewhat limited I am going
to pre-emptively push this out.
Signed-off-by: Nick Schwaderer <nschwaderer@chef.io>
At the moment we return the "Truncate" text whenever the setting is
utilized. This PR ensures that we only advise truncation when it's been
executed.
Signed-off-by: Nick Schwaderer <nschwaderer@chef.io>
Fixes#5131
Due to the use of `#split(‘=‘)` against inputs supplied via the CLI we had an edge case where inputs with `’=‘` in the value would cause a breakage.
This PR supplies a test for the regression and fixes the bug with a regex solution.
Signed-off-by: Nick Schwaderer <nschwaderer@chef.io>
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>