| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
| |
Move the data_query, powershell and registry_helper DSLs up to universal.
Move the `tagged?` helper into data_query for organizational purposes.
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
|
|
|
|
|
|
|
| |
This just gives us a line count to the change and perhaps a starting
point for when we do this in Chef 15
Signed-off-by: Tim Smith <tsmith@chef.io>
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
We wired these up previously with deprecations. They've been deprecated for a long time and are pretty rarely used on the Supermarket. Additionally we have Foodcritic rules to detect their usage:
FC102: Deprecated Chef::DSL::Recipe::FullDSL class used
FC100: Deprecated Chef::Mixin::Language mixin used
FC099: Deprecated Chef::Mixin::LanguageIncludeRecipe mixin used
FC098: Deprecated Chef::Mixin::RecipeDefinitionDSLCore mixin used
FC097: Deprecated Chef::Mixin::LanguageIncludeAttribute mixin used
Signed-off-by: Tim Smith <tsmith@chef.io>
|
|
|
|
| |
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
|
|
|
|
|
| |
I think this happened when we merged the Opscode and Chef copyrights
Signed-off-by: Tim Smith <tsmith@chef.io>
|
| |
|
|
|
|
| |
this is for DSL methods that get mixed in everywhere.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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.
|
|
|
|
|
|
| |
Chef::DSL::Recipe::FullDSL.send(:include, MyModule) will now patch all
its descendants that it has been included into (works the way actual
inheritance works now).
|
|
|
| |
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"
|
|
|
|
|
|
| |
See chef/chefstyle#11 for analysis and discussion. We select '{}' since
audit of our source code shows that is the most common, and that used to
be the dominant learning paradigm (e.g. in ruby 1.9 pickaxe book.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
- extract to its own mixin so it can be included without
method_missing and the rest of the resources DSL
- add ability to inject different run_context
- add ability to create_if_missing into the resource_collection
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
- Declare all resource DSL as methods on Chef::DSL::Resources
- Declare all definition DSL as methods on Chef::DSL::Definitions
|
|
|
|
| |
unexpected order
|
| |
|
|
|
|
|
|
|
| |
Turns the 3694 warning into a debug message if the prior resource is
identical to the current resource. Suggestion for opscode/chef-rfc#76
This also moves resource building out to its own class.
|
|
|
|
|
|
| |
Fixing some code I changed unecessarily
Removing TODOs which are not necessary
|
|
|
|
|
| |
makes resource and provider class resolution more dynamic.
begins deprecation of Chef::Platform static mapping.
|
|\
| |
| | |
Notify a resource by the `resource[name]` key it was written as
|
| | |
|
| |
| |
| |
| | |
specs continue to pass, removing ResourceSet and ResourceList from consumer knowledge
|
| | |
|
|/
|
|
|
|
|
| |
this can allow method chaining so that if you call a definition to
create a resource, and the definition takes the time to return the
resource as its retval, then you can hang a .not_if off of the
definition (or .only_if/.notifies/.subscribes/etc)
|
| |
|
| |
|
|
|
|
| |
with in resource collection.
|
| |
|
|
|
|
| |
without circular dependencies or missing deps
|
|
|
|
|
| |
Depending on the inheritance tree, the default implementations could
incorrectly be preferred to the real ones.
|
|
|
|
| |
merge issues
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
* Make deprecated constants in Chef::Mixin available by loading the
relevant files from the chef/dsl files that replace them.
* Add deprecation warnings via const_missing hook.
|