| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* removes the mutation of the new_resource.version
* adds package_class_supports_arrays for multipackage providers
* cleans up the package resource initializer and sets the package_name
correctly through the accessor method.
By mutating new_resource.version we were destroying the original intent
of what the user was requesting. This is a bug that must be fixed.
Generally, subclasses will be able to get the correct information they
need through either the version argument they were passed in
install_package(name, version) instead, or through their
`#target_version_array` method. If this breaks anything then those
providers need bugfixes as well (since this is a change to an internal
API accessible only to subclassing, and there are backwards compatible
and correct ways to get the information, this is *not* a SemVer
violating change). See the fix I made to the OpenBSD provider to
preserve the same semantics, avoid using new_resource.version where it
was inappropriate, and make the code more symmetrical where before
substantially different looking code in install_package and
remove_package had exactly the same ultimate effect.
The package_class_supports_arrays 'DSL' for writing multipackage
providers coerces the arguments to the virtual methods (e.g.
install_package) into arrays, even if the user is only requesting a
single package install. This removes most of the `is_a?(Array)`
checks from the implementation subclasses.
The cleanup of the initializer is similarly necessary so that we can
use Chef 12.5 coercions to make the package_name and version arguments
accept string, but always be Arrays. This should eliminate the rest
of the need to write `is_a?(Array)` code all over the package provider
implementations.
|
| |
|
|
| |
- Warn when multiple providers try to provide the same thing
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
updates all the shell_out calls to respect the timeout which is passed
on the new_resource.
the old `Chef::Config` yum timeout values are still respected and will
override the default.
the default of 900 seconds is preserved.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Allow the `package` provider to take an array of packages to handle in one
transaction.
This solves two large problems:
* There are times when you cannot install two packages in sequence, like when a
binary is moving between two packages - they *must* be done in the same
transaction.
* When using Chef to install the vast majority of your base system, it
can make imaging take a very, very long time because executing yum or apt once
for every single package is painfully slow.
This solves both. The scaffolding is all there in the Package HWRP, plus the
underlying implementation for both apt and yum, the two I have access to test.
|
| |
|
|
| |
functionality to fix resource notifications and ChefSpec stubs.
|
| |
|
|
|
|
|
|
| |
Now that Chef properly supports a package `response_file` using
`Chef::Resource::Template`, the Package resource should implement the
`response_file_variables` method so that variables do not have to exist
as node attributes (eg - for seeding DB passwords for configuration
files generated by packages).
|
| |
|
|
| |
The opscode/chef repository now only contains the core Chef library code
used by chef-client, knife and chef-solo!
|
| |
|
|
| |
all with proper deps
|
| | |
|
| |
|
