This version is compatible with:
- Puppet Enterprise 2019.8.x, 2019.7.x, 2019.5.x, 2019.4.x, 2019.3.x, 2019.2.x, 2019.1.x, 2019.0.x, 2018.1.x, 2017.3.x, 2017.2.x, 2017.1.x, 2016.5.x, 2016.4.x
- Puppet >= 4.0.0 < 7.0.0
Start using this module
Welcome to your new module. A short overview of the generated parts can be found in the PDK documentation.
The README template below provides a starting point with details about what information to include in your README.
Briefly tell users why they might want to use your module. Explain what your module does and what kind of problems users can solve with it.
This should be a fairly short description helps the user decide if your module is what they want.
If it's obvious what your module touches, you can skip this section. For example, folks can probably figure out that your mysql_instance module affects their MySQL instances.
If there's more that they should know about, though, this is the place to mention:
- Files, packages, services, or operations that the module will alter, impact, or execute.
- Dependencies that your module automatically installs.
- Warnings or other important notices.
If your module requires anything extra before setting up (pluginsync enabled, another module, etc.), mention it here.
If your most recent release breaks compatibility or requires particular steps for upgrading, you might want to include an additional "Upgrading" section here.
The very basic steps needed for a user to get the module up and running. This can include setup steps, if necessary, or it can be an example of the most basic use of the module.
Include usage examples for common use cases in the Usage section. Show your users how to use your module to solve problems, and be sure to include code examples. Include three to five examples of the most important or common tasks a user can accomplish with your module. Show users how to accomplish more complex tasks that involve different types, classes, and functions working in tandem.
This section is deprecated. Instead, add reference information to your code as Puppet Strings comments, and then use Strings to generate a REFERENCE.md in your module. For details on how to add code comments and generate documentation with Strings, see the Puppet Strings documentation and style guide
If you aren't ready to use Strings yet, manually create a REFERENCE.md in the root of your module directory and list out each of your module's classes, defined types, facts, functions, Puppet tasks, task plans, and resource types and providers, along with the parameters for each.
For each element (class, defined type, function, and so on), list:
- The data type, if applicable.
- A description of what the element does.
- Valid values, if the data type doesn't make it obvious.
- Default value, if any.
### `pet::cat` #### Parameters ##### `meow` Enables vocalization in your cat. Valid options: 'string'. Default: 'medium-loud'.
In the Limitations section, list any incompatibilities, known issues, or other warnings.
In the Development section, tell other users the ground rules for contributing to your project and how they should submit their work.
If you aren't using changelog, put your release notes here (though you should consider using changelog). You can also add any additional sections you feel are necessary or important to include here. Please use the
- fix: avoid mangling names when resource target is a url (#110)
- compatibility: first release to officially support Puppet 5 (previous versions worked unofficially)
- fix: fix installation of first-ever Brew package on machine (#98)
- feature: support multi-user environments with new
- fix: support for High Sierra
- compatibility: drop support for Puppet 3
- fix: include ruby 1.8.3 in metadata.json
- compatibility: last release to include Puppet 3 support
- feature: allow usage within non-brew and bundler environments
- feature: support ruby 1.8.3 installations
- meta: more and better linting
- feature: permission management more closely aligns to brew install
- bugfix: ensure providers load regardless of configured puppet load order
- bugfix: ensure facts work on all puppet versions
- bugfix: ensure packages with 'homebrew-' prefix are not re-installed
- bugfix: do not allow homebrew root install
- feature: allow package to set HOMEBREW_GITHUB_API_TOKEN
- feature/bugfix: stop parsing homebrew output, parse response codes instead
- bugfix: manage /usr/local/Homebrew rather than parent directory
- meta: speed up tests
- bugfix: manage objects (packages, taps, etc) case-insensitively
- meta: deprecate root-owned homebrew
- meta: clean up tests
- bugfix: fixed bug where brew-cask provider didn't work the first time
- meta: updated to new homebrew install location
- feature: allow usage by any member of homebrew group
- feature: remove files with invalid checksums for easier retrying
- bugfix: ensure
- bugfix: detect and fail properly on checksum errors
- meta: include README section on ordering taps/packages
- feature: allow user/group override
- bugfix: remove
errfrom facter code
- bugfix: fix compat issues for facter booleans
- bugfix: use puppet warning over ruby warn
- bugfix: only download CLI tools if values are set
- meta: move away from params class
- feature: allow users to manage taps
- meta: better testing, OSX-specific tests on Travis
- meta: fix typos, add contributer list
- bugfix: set directory permissions to brew defaults
- bugfix: fix brewcask parsing
- meta: enable auto-testing
- bugfix: ensure brew is called with correct user
- feature: add install_options
- feature: add upgradeable
- tech debt: clean up inheritance pattern
- documentation fixes
- initial release
- puppetlabs/stdlib (>= 4.2.0 < 7.0.0)