Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Chef 12.9 introduced apt_respository resource #712

Closed
miketheman opened this issue May 16, 2016 · 2 comments
Closed

Chef 12.9 introduced apt_respository resource #712

miketheman opened this issue May 16, 2016 · 2 comments

Comments

@miketheman
Copy link
Contributor

In chef/chef#4782 the apt_repository resource has been ported to core chef, released in 12.9.37.

When using the apt cookbook, (which provides matchers), a warning is emitted, due to two providers existing at the same time.

[2016-05-16T08:56:20-04:00] WARN: Chef::Provider::AptRepository already exists!  Cannot create deprecation class for LWRP provider apt_repository from cookbook apt
[2016-05-16T08:56:20-04:00] WARN: AptRepository already exists!  Deprecation class overwrites Custom resource apt_repository from cookbook apt

This is expected behavior, as far as I can tell.

However, when removing the use of the apt cookbook from metadata.rb, a failure is raised:

Failure/Error: expect(chef_run).to add_apt_repository('nginx.org')
     NoMethodError: undefined method `add_apt_repository'

Since ChefSpec now has no notion of an add_apt_repository matcher.

  • Should ChefSpec be responsible for including matchers for resources that are being ported from cookbooks to core? It seems so, and will need the addition of @not_chef_xxx block prior to a test example, like this one
  • How will ChefSpec behave when there are multiple matchers of the same name, in the event that a user decides to continue to use the external cookbook?
  • Is it desirable to create a PR with the new resource for the next version of ChefSpec?
@sethvargo
Copy link
Contributor

Hey @miketheman

Thank you for opening an issue. ChefSpec should be responsible for including those matchers, but I typically wait a few weeks until there's more adoption of the release.

This is a bit of an edge case, but I think ChefSpec should prefer the cookbook-defined matcher over the core. This allows users to customize matcher behavior and doesn't break bc (i.e. someone currently using the cookbook doesn't suddenly inherit a new matcher on a CS upgrade). I, however, have to figure out how to do that 😄

Is it desirable to create a PR with the new resource for the next version of ChefSpec?

Yes, but I think I need to build some kind of framework in core that provides a method like matcher_defined? first.

@cullenmcdermott
Copy link

Hi @miketheman and @sethvargo,

I submitted #709 last week which should fix this. Does it meet your requirements? If not, what can I do to make it meet them?

@lock lock bot locked as resolved and limited conversation to collaborators Aug 3, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants