| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
We have some extra conditionals that aren't getting us anything
Signed-off-by: Tim Smith <tsmith@chef.io>
|
| |
|
|
|
|
|
| |
This gives a speed boost since rubygems does not have to scan through
every gem in the gemset in order to find the file.
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| |
|
|
| |
Signed-off-by: Thom May <thom@chef.io>
|
| |
|
|
|
|
|
| |
I think this nukes descendants tracker, although might need to clean it
up in a few more spots.
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The old action_class code was doing some magical stuff with the provider
accessor in order to determine if the class was supposed to be a custom
resource or not and have the action_class autovivifying accessor return nil
in cases when the resource wasn't a custom resource and implementing
inheritance by walking back up the tree in ways that were difficult to
grok.
This removes the magic from the provider so that there's no longer any
accessor that magically short-circuits to nil if the resource is not
supposed to be a custom resource.
There is now a simple inherited API for `Chef::Resource.custom_resource?`
which just defines if the class is a custom resource or not. Since both
`action` and `action_class` call `define_action_class` they both wind up
setting this boolean on the class, which is then inherited to subclasses
automatically, which eliminates the need to walk up the hierarchy.
The superclass.respond_to?(:action_class) checks have also been rendered
unnecessary by removing the code that walked up the inheritance
hierarchy and also because Chef::Resource is never going to be a
custom resource itself, so will never call `define_action_class` so from
inside of `define_action_class` you can always rely on the superclass
being a resource and implementing `custom_resource?` and `action_class`.
The wiring for picking the provider is now moved explicitly to the
ProviderResolver -- even though custom resources hardcode a 1:1
resource-to-provider mapping. This reads much clearer to me than the
magical wiring to the provider accessor off of the instance.
The bug that this fixes was that the way the magical accessor
nil-or-action_class was implemented the old way of defining action
helpers with class_eval broke:
```ruby
action_class.class_eval << EOM
def a
"foo"
end
EOM
```
If that came before any action_class-with-a-block or action declaration
and the resource did not inherit from another custom resource then the
action_class would not be created and it would return nil, which was an
API which the magical wiring in the provider accessor required.
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| |
|
|
|
|
| |
forgot to branch and need more coffee
This reverts commit 02ec917f9356d999c44aceb7f1ff43957b0fe832.
|
| |
|
|
|
|
|
| |
I think this nukes descendants tracker, although might need to clean it
up in a few more spots.
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| |
|
|
|
|
| |
Switch over the Chef-12.0 ProviderResolver is now completed.
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| |
|
|
|
|
|
| |
no, we should not do this only in why-run mode, add more yapping to
make that clear.
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| |
|
|
|
|
|
|
| |
This adds URLs to each class of deprecation, and correctly prints and
formats them for maximum user efficiency. We also provide the URL to the
data collector for Visibility to ingest.
Signed-off-by: Thom May <thom@chef.io>
|
| |
|
| |
Generated via git ls-files | xargs perl -pi -e "s/[Cc]opyright (?:\([Cc]\) )?((?\!$(date +%Y))\\d{4})(-\\d{4})?([, ][ \d]+)*(,|(?= ))/Copyright \\1-$(date +%Y),/g"
|
| |
|
|
|
|
|
| |
This is an entirely mechanically generated (chefstyle -a) change, to go
along with chef/chefstyle#5 . We should pick something and use it
consistently, and my opinion is that double quotes are the appropriate
thing.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
over priority
|
| | |
|
| |
|
|
|
|
| |
"look at all classes to see if they provide the DSL" else clause
when you're just setting resource_name (which happens on every
class). Perf fix for tests.
|
| | |
|
| |
|
|
| |
in Provider
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
provides? on a provider was passed the full resource. provides? on
a resource class cannot be passed the resource and must be passed the
declared_type instead. i tried to make them the same, but that would
change the API on the provider.
|
| |
|
|
| |
This reverts commit 57cdbe124f63e47cab960e714572539d3979b90f.
|
| |
|
|
|
|
|
| |
provides? on a provider was passed the full resource. provides? on
a resource class cannot be passed the resource and must be passed the
declared_type instead. i tried to make them the same, but that would
change the API on the provider.
|
| |
|
|
| |
also wire them up through the Chef class.
|
| |
|
|
|
|
| |
move the sorting of the providers to after we make the first cut, still
keeps deterministic ordering, but avoids sorting providers we are just
going to throw away.
|
| |
|
|
|
|
|
|
| |
* makes provides? more correct for linux services
* makes supports? more targetted for linux services
* remove provider_resolver from the run_context
* fix timestamped deploy spec
* add more specs
|
| | |
|
| |
|
|
|
| |
makes resource and provider class resolution more dynamic.
begins deprecation of Chef::Platform static mapping.
|
| |
|
