Helps with Customer Bug 236 (see there for repro)
Currently, when we run `inspec compliance upload my_profile` it is
cached locally in inspec when run. If we update the version in the core
code and run another upload, `inspec compliance upload my_profile` again
it will run the old cached version instead of running a new copy
from automate.
The current workaround is to specify the desired version with
`inspec exec compliance://my_profile/admin#0.1.1`.
The caching happens before we have forward sight into the profile's
contents and only the target name. So the text used to generate the
cache would be `compliance://my_profile/admin` which does not change
version to version.
A fix here could simply identify when we are doing a local `inspec exec
compliance://` (hitting local profiles does not generate a cache) and
skips the cache if there's no version specified. That would eliminate
the unexpected behavior. However, it is a breaking change for customers
as some current caching taking place would no longer take place.
Instead, we have included a `clear_cache` cli method for InSpec,
which should assist the core team and other developers in the future
when debugging edge case issues in InSpec.
Signed-off-by: Nick Schwaderer <nschwaderer@chef.io>
The existing documentation explicitly claims that not specifying “run” in a waiver is equivalent to specifying “run: false.” It turns out to be the case that the claim is completely false. This commit includes a test for a new control 18_waivered_no_expiry_default_run that behaves exactly like the control 04_waivered_no_expiry_ran_fails. That is, not specifying run in a waiver is the same as specifying “run: true.”
Signed-off-by: David Marshall <dmarshall@gmail.com>
The tests depended on an old fixture profile that skipped a test,
which no longer happens. It also was targeting a test that does not exist.
Signed-off-by: Clinton Wolfe <clintoncwolfe@gmail.com>
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>
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>
