| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
data-collector message.
Signed-off-by: Josh Hudson <jhudson@chef.io>
|
| |
|
|
| |
Signed-off-by: Josh Hudson <jhudson@chef.io>
|
| |
|
|
|
|
| |
cookstyle cleanup in the file.
Signed-off-by: Josh Hudson <jhudson@chef.io>
|
| |
|
|
|
|
| |
data-collector
Signed-off-by: Josh Hudson <jhudson@chef.io>
|
| | |
|
| |\
| |
| | |
bumping acceptance gems
|
| |/
|
|
| |
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| | |
|
| |\
| |
| | |
set default guard_interpreter to powershell_script
|
| |/
|
|
| |
Signed-off-by: Tor Magnus Rakvåg <tm@intility.no>
|
| | |
|
| |\
| |
| | |
Chef-13: remove more deprecated provider_resolver code
|
| | |
| |
| |
| | |
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| | |
| |
| |
| |
| |
| |
| | |
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>
|
| | | |
|
| |\ \
| | |
| | | |
fix ruby-2.4 func link tests on solaris 11
|
| | | |
| | |
| | |
| | | |
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| |/ /
| |
| |
| |
| |
| |
| | |
i suspect linux is the buggy one and everyone else is posix
compliant...
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| | | |
|
| |\ \
| | |
| | | |
pull omnibus-software fix for windows builds
|
| | | |
| | |
| | |
| | | |
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| | | | |
|
| |\ \ \
| |/ /
| | /
| |/
|/| |
bumping omnibus lockfile
|
| |/
|
|
| |
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| | |
|
| |\
| |
| | |
Chef-13: Make ActionClass a class
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
since any ActionClass literally is-a Chef::Provider it should just
use inheritance and then we don't have to use the hacky hooks for
class methods in modules and it becomes more clear from the
ActionClass source what it is and what it does.
Bonus starts the deprecation of properties being injected into the
provider namespace.
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| |\ \
| | |
| | | |
disable nokogiri on windows for now
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
nokogiri does not have a ruby-2.4 release for windows
this is slightly complicated because we still need nokogiri in the
Gemfile.lock for travis.
i'm starting to think we should have a Gemfile.travis and
Gemfile.travis.lock or something and stop using groups for that.
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| |\ \ \
| |_|/
|/| | |
Retry API requests if using an unsupported version
|
| | | |
| | |
| | |
| | | |
Signed-off-by: Thom May <thom@chef.io>
|
| | | |
| | |
| | |
| | |
| | |
| | | |
Also tidy up in the face of the real world.
Signed-off-by: Thom May <thom@chef.io>
|
| | |/
|/| |
|
| |\ \
| | |
| | | |
bump _XOPEN_SOURCE to 600 for ruby 2.4 on Solaris
|
| | | |
| | |
| | |
| | |
| | |
| | | |
unbreaks builds.
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| |/ / |
|
| |\ \
| | |
| | | |
bumping everything
|
| | | |
| | |
| | |
| | | |
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| | | |
| | |
| | |
| | | |
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| |/ /
| |
| |
| | |
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| | | |
|
| |\ \
| |/
|/| |
Use the ruby 2.4.1 release
|
| | |
| |
| |
| | |
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| | |
| |
| |
| | |
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| | | |
|
| |\ \
| |/
|/| |
Fix action class weirdness in Chef-13
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | | |
chef/afiune/COOL-691/make-resource-reporter-smarter-to-access-identity
Make ResourceReporter smarter to get resource identity and state
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Lets make the ResourceReporter smarter, we will try to get the identity
and state (after and before) of the resource but if we can't because of
an Exception, lets sends a message to the data collector containing a
static resource identity since we were unable to generate a proper one.
The problem is coming from the ResourceReporter, when it is trying to
report back the resource identity and state, it is using basic methods
from the Base class that should be secure to call from eny subscriber.
This is actually not a bug since Chef is doing the right thing, that is
to throw an error when the identity property is nil (or is not the right
kind that we configured for) so, rather than making identity properties
smarter for lazy evaluation we are going to make the ResourceReporter a
bit smarter so that it doesn't explode when the use configured a
resource with a wrong identity property.
Closes https://github.com/chef/chef/issues/5490
Signed-off-by: Salim Afiune <afiune@chef.io>
|
