Inspec-1.51.* fail with --concurrency option in kitchen #167
I just found out a bug and I am not sure if the issue is within kitchen-inspec or inspec itself.
If I remove the --concurrency option the kitchen verify finishes without issue.
Here are the version I tried:
It works with inspec-1.49.2 though.
I could not test it with inspec-2.* because I have the following issue, even though I have inspec-2.0.17 installed. Should I open another issue about that or is it an issue on my end only ?
Let me know if you need any more informations
The text was updated successfully, but these errors were encountered:
The first error we would need some more context, namely the .kitchen.yml and the concurrency value passed (ideally the actual command). The latter failure means that whatever kitchen binary you are using can't see kitchen-inspec, this is probably a local environment condition - i.e. ChefDK not installed correctly or something not set correctly in the .kitchen.yml.
I'll check the second error later :)
Hitting on me as well.
Seems that we have a nice race condition here
Its a bit tricky to implement parallel execution. The challenge is not so much in inspec itself, the challenge is that we use RSpec undercover and its creating a global state. I see two doable options:
Essentially, we need to make sure that the execution context is not shared
@gionn has an excellent workaround. Thank you for sharing!
This has been re-created with the kitchen-vcenter driver as part of the testing for chef/chef-workstation#1442 and test-kitchen/test-kitchen#1677. TK 1677 allows plugins to declare that they are not thread safe - which as was mentioned is not possible for InSpec due to RSpec being non-thread safe - see RSpec discussion.
TK 1678 enables this plugin to declare that is not thread safe and the Verify stage should be run serially, which in my testing has been stable and a negligible slowdown under vcenter, vagrant, and docken.