| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
Fixes #6300.
This may be a breaking change.
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is inspired by "use_inline_resources".
Setting `unified_mode false` in a resource would be the existing
behavior with separate compile/converge phases.
Setting `unified_mode true` in a resource will eliminate the converge
phase. Reverse notifications and delayed notifications will still
fire. The resource action will behave like all resources are executing
at compile time.
As a aside, notifications have never worked for resources firing at
compile time. This implementation gets that behavior correct so
that notifications will work.
Of course forward immediate notifications to resources not yet declared will not
be possible.
Setting `resource_unified_mode_default true` in `Chef::Config` would
turn off the split compile/converge mode for every custom resource.
NOTE: This does not affect recipe mode at all.
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
|
|
|
|
|
| |
enforce pretzels.
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
|
|
|
| |
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
|
|
|
| |
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
|
|
|
|
|
|
|
|
| |
Stops the kernel from scanning through all the activated gems every time in order
to resolve names into pathnames.
See rubygems/rubygems#2762
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
| |
A pile of misc yard I added as I was reading things.
Signed-off-by: Tim Smith <tsmith@chef.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was dropped in Chef 14.0.190 by chef/chef#6952 as a side effect
of stripping out all the Chef::Resource automagic delegators.
People were using this one inside of provider code, and it seems fine
to continue to use it.
Moving it to inject it directly into the Provider class instead of
just custom resource action_classes to make our API more consistent.
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
|
|
|
| |
Signed-off-by: Thom May <thom@chef.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
require writing `new_resource.my_property` instead of just
`my_property` in provider code.
a surprise in this code was that methods directly on the
resource are all injected into the provider, and we never
deprecated that, because we didn't know about it.
that makes `action_class {}` helpers unnecessary, but causes
additional namespace pollution, but at least the methods declared
in the resource will lose to DSL methods (i.e. `def execute`
will not work).
but that also means that resources which are injected into the DSL
which overwrite resource methods in other cookbooks may break
their use in that cookbooks providers/action_classes.
we should probably deprecate that as well, but we didn't and
people probably found this behavior and used it.
i cleaned it up a bit and removed the methods on Chef::Resource
directly which polluted the provider class with all kinds of
bizzare crap methods (not_if and only_if were getting injected
into the provider, etc).
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
|
|
|
| |
Signed-off-by: Thom May <thom@chef.io>
|
|\
| |
| | |
prepping for rubocop 0.52.1
|
| |
| |
| |
| | |
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
|/
|
|
| |
This reverts commit aab192e2b5df57d13213f8e89ce6fccc74a01db1.
|
|
|
|
|
|
| |
Toss in some yard while I'm in here as well
Signed-off-by: Tim Smith <tsmith@chef.io>
|
|
|
|
| |
Signed-off-by: Chris Arnold <cma.arnold@gmail.com>
|
|
|
|
| |
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
|
|
|
|
|
|
| |
This forces everyone to starting using new_resource.property_name
instead of just property_name.
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
|
|
|
|
|
|
|
| |
in a single cookbook codebase.
The test is left in pending mode so it will automatically remind us by failing in six months.
Signed-off-by: Noah Kantrowitz <noah@coderanger.net>
|
|
|
|
| |
Signed-off-by: Noah Kantrowitz <noah@coderanger.net>
|
|
|
|
| |
Signed-off-by: Noah Kantrowitz <noah@coderanger.net>
|
|
|
|
| |
Signed-off-by: Noah Kantrowitz <noah@coderanger.net>
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
we did actually have tests around creating actions with spaces and
hyphens in their names. we had fallback code for properties, but it
was broken and threw a "private method define_resource called" and then
it created a closure and didn't have the `name` in the binding so it
called itself and blew up the stack.
this change walks that back. it does prove that we still support
UTF-8 in property names, actions and DSL names, which i'd argue is
more than enough.
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
|
|
|
|
|
|
| |
this should fix several bugs in providers that look like they should
support whyrun but fail to declare it.
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>
|
|
|
| |
sensitive is the property of the resource, not the provider.
|
| |
|
|
|
|
|
| |
deprecates chef_rewind functionality completely and adds a few
more features
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* removes the DSL from InlineResources class
* ActionClass is now responsible for mixing the DSL into
action classes
* apt_update provider converted over to use new syntax
- does not need to mixin DeclareResource DSL
- declares use_inline_resources
- uses declare_resource instead of build_resource
- converts def action_stuff to action :stuff
- uses an execute resource instead of shell_out!
- does not need the converge_by to update the action
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- creates Chef::DSL::MethodMissing which will be nuked in Chef 13
- creates Chef::DSL::Core which is the mixins into core providers
- adds build_resource/define_resource to core providers
The intent here is to create Chef::DSL::Core which is intended to
become the DSL minus method_missing and things that are only intended
for recipes. Right now I've only added build_resource/declare_resource
to core providers. We should probably push more into the "Core" DSL
so that core providers could do things like use the search API.
I would have moved everything other than resources and definitions over
but the audit mode stuff is really only appropriate for recipes and not
provider code and probably should not be moved over. We should probably
have an intermediate mixin which is the "Custom Provider" DSL that has
Resources and Definitions mixed into it, but which does not mix in the
audit stuff that should only go into the Recipe DSL.
There may also be a "Resources DSL" which has mixins for use with
not_if/only_if and I'm unclear if that should be the "Core DSL" or
another fourth mixin of DSL files.
|
|
|
|
|
|
|
|
| |
this module was created out of a bit of excessive paranoia instead of
simply adding mixins that we always use with Chef::DSL::Recipe directly
to Chef::DSL::Recipe. lets try and YAGNI this class and just add it
directly. these modules are already injected into everyone's recipes
and providers, so I can't imagine a huge amount of backcompat breaks.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
4174 Style/SpaceInsideHashLiteralBraces
1860 Style/SpaceAroundOperators
1336 Style/SpaceInsideBlockBraces
1292 Style/AlignHash
997 Style/SpaceAfterComma
860 Style/SpaceAroundEqualsInParameterDefault
310 Style/EmptyLines
294 Style/IndentationConsistency
267 Style/TrailingWhitespace
238 Style/ExtraSpacing
212 Style/SpaceBeforeBlockBraces
166 Style/MultilineOperationIndentation
144 Style/TrailingBlankLines
120 Style/EmptyLineBetweenDefs
101 Style/IndentationWidth
82 Style/SpaceAroundBlockParameters
40 Style/EmptyLinesAroundMethodBody
29 Style/EmptyLinesAroundAccessModifier
1 Style/RescueEnsureAlignment
|
|
|
| |
Generated via git ls-files | xargs perl -pi -e "s/(Author.*?<[^@]+@)(?:opscode\\.com|getchef\\.com)(>)/\\1chef.io\\2/gi"
|
|
|
| |
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.
|
| |
|
|
|
|
| |
useless use of `"#{foo.to_s}"`
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|