| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
If no other property is an identity property then the name_property is
the default identity property. The name_property is also marked as not
being desired state by default (the 'name' should never change).
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
|
|
|
|
|
| |
We need this information so we can generator documentation that includes these values.
Signed-off-by: Tim Smith <tsmith@chef.io>
|
|
|
|
| |
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
|
|
|
|
|
| |
Let's make sure we don't revert this by accident
Signed-off-by: Tim Smith <tsmith@chef.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The original comparison `value == NOT_PASSED` ends up calling `.<=>` on
value under the hood. This relies on the implementation of `<=>`/`cmp`
not being broken in that class.
Unfortunately, some classes like OpenSSL::X509::Name have broken
implementations of `<=>` that raise TypeError instead of returning nil
for mismatched types. https://github.com/ruby/openssl/pull/264
As a result, currently, if you attempt to set a resource property to an
OpenSSL::X509::Name object, the result is a TypeError.
With this change, we use the implementation of comparison from the
NOT_PASSED object instead, which we know will work no matter what.
Signed-off-by: Andy Brody <git@abrody.com>
|
|
|
|
| |
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
|
|
|
|
|
| |
start enforcing using %i{} instead of arrays of symbols
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
|
|
|
|
|
|
| |
i like this one, gives visual priority to returns or raises that are
buried in the middle of things.
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>
|
|
|
|
|
|
|
|
|
| |
skip_docs is used to specify a property that we don't want to include in the documentation. We have several of these.
default_description is used to describe the default in a way we'd want to put on the docs site. This is particularly useful for describing all our lazy / computed values.
I've used both of these in resources to show how I think we'll use them.
Signed-off-by: Tim Smith <tsmith@chef.io>
|
|
|
|
|
|
|
| |
absolutely hard requirement on the fixes that went into chef-config 2.2.11, so the
floor of that gem is bumped up.
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
|\
| |
| | |
Setting nil to properties with implicit nil sets default value
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- This makes converting core resources to properties safer
- This makes it easier to apply wrapping properties to subresources
property :foo, String, default: "foo"
This is where the change lies, and writing a nil here will now actually
write a "foo" to the variable.
property :foo, [ String, nil ], default: "foo"
This is unchanged. Writing nil writes nil.
property :foo, String
Technically this is changed, since it writes the default value, but
since nil.equal?(nil) in a very deep way no behavior changes.
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
|/
|
|
|
|
|
|
|
|
|
| |
* `deprecated_property_alias` allows the resource author to provide
transition from old properties to new ones with a deprecation
warning.
* The `deprecated` option on a property emits a deprecation warning.
* The `deprecated` method on a resource takes a message, but does not
yet emit a deprecation warning.
Signed-off-by: Thom May <thom@chef.io>
|
|
|
|
|
|
|
|
|
|
|
| |
this is effectively dead because of forcing new_resource.thingy
i stuck a hard `raise` in here and we have no tests around this any
more.
the conditional also just makes my head hurt looking at it.
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
|
|
|
| |
Signed-off-by: Thom May <thom@chef.io>
|
|
|
|
| |
Signed-off-by: Thom May <thom@chef.io>
|
|
|
|
|
|
| |
Give more details on why people are seeing these problems so they can fix them.
Signed-off-by: Tim Smith <tsmith@chef.io>
|
|
|
|
| |
Signed-off-by: Noah Kantrowitz <noah@coderanger.net>
|
|
|
|
| |
Signed-off-by: Noah Kantrowitz <noah@coderanger.net>
|
|
|
|
| |
Signed-off-by: Noah Kantrowitz <noah@coderanger.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
| |
redefining Object#hash or any other Object/Chef::Resource method is now prevented.
overriding inherited properties is allowed.
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
|
|
|
|
|
|
| |
remove deprecations and now properties are nillable and passing a nil is
now always a set, not a get.
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
This removes all the magic that attempts to allow users to write unsafe
properties - ie, ones that set a default but claim to be a name
property. This yielded different results depending on ordering. It's
better for our users to just suck up fixing this.
Closes: #5542
(Part of #3705)
Signed-off-by: Thom May <thom@chef.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When creating a resource, a user can create a property that is the same
name as an already-existing Ruby method, such as `#hash`. In the case of
the `#hash` method, this can cause issues when attempting to adding
resources to other data structures, such as Arrays or Hashes. In other
examples, this could cause unexpected behavior that is incredibly
difficult to troubleshoot.
This change adds a deprecation warning in the case where a user adds
a property to a resource that the resource instance already responds to.
If y'all are OK with this approach, I'll be happy to write up the
deprecation doc for this for docs.chef.io.
Signed-off-by: Adam Leff <adam@leff.co>
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
| |
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some properties in custom resources may include sensitive data, such as a
password for a database server. When the Resource's state is built for use by
Data Collector or similar auditing tool, `Chef::Resource#state_for_resource_reporter`
builds a hash of all state properties for that resource and their values. This
leads to sensitive data being transmitted and potentially stored in the clear.
This change enhances properties with the ability to set an individual property
as sensitive and then have the value of that property suppressed when exporting
the Resource's state.
|
|
|
|
| |
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
|
|
|
|
|
|
|
| |
- clean up "ZenMaster" resource
- clean up 3694 detection to use properties
- unlazy the resource_name in the trivial resource check
- fixes an issue with resources-as-definitions pattern emitting
3694 errors for trivial resources
|
|
|
|
|
|
| |
in Chef-13 nillable will become 'true' by default and we'll have
to deprecate and remove all nillable properties, but for now
this lets us opt-in, which was can't currently do in Chef-12.
|
|
|
|
| |
'nil_set' parameter to get() to skip a spurious warning when that happens.
|
|
|
| |
one in Chef::Mixin::Properties would result in duplicated values.
|
|
|
|
| |
this looks nicer.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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/[Cc]opyright (?:\([Cc]\) )?((?\!$(date +%Y))\\d{4})(-\\d{4})?([, ][ \d]+)*(,|(?= ))/Copyright \\1-$(date +%Y),/g"
|
|
|
|
| |
`property_type(is: [:a, :b], default: :c)` was broken because ParamsValidate requires its input to have a name and property types don't have one.
|
| |
|
|
|
|
|
|
| |
1. Warn when default values are invalid.
2. Never validate nil (on set or get) if there is no default.
3. Emit "will be invalid in Chef 13" warning when setting an invalid nil value.
|
|
|
|
| |
unless using properties on the resource
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
actually change. Gets rid of cases where we are initializing a
resource with values from another resource.
|
| |
|
| |
|
|
|
|
| |
(User will expect "x x" to grab the parent property.)
|
| |
|
| |
|
| |
|