You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was wanting to use the gem_package resource because the package resource doesn't work for gems installed and I was rudely woken up to our static list of resources we register.
Introspecting Chef to find the available resources your version of Chef supports is a great idea, and something I've also been considering for chefspec to remove a lot of boilerplate in that project.
One slight complication for minitest-chef-handler is that it was a conscious decision not to implement matchers for resources that extend File (see this comment) and it would be good to preserve that behaviour.
We also treat a couple of resources differently because they need more than just the resource name in order to #load_current_resource. Again we could special case those.
For people that use the MiniTest::Spec syntax we'd also want to think about adding infections perhaps based on parent class.
The only downside I can see is that the code may become slightly harder to follow.
I was wanting to use the gem_package resource because the package resource doesn't work for gems installed and I was rudely woken up to our static list of resources we register.
cron directory file group link package service and user are covered but it omits gem_package and other resources that may come up in the future.
It's easy to register gem_package but that feels wrong.
Thanks!
The text was updated successfully, but these errors were encountered: