/
README.md.erb
118 lines (81 loc) · 4.14 KB
/
README.md.erb
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
<%- name = @configs['module_metadata']['name'].split('-').last rescue '[modulename]' -%>
# <%= name %>
Welcome to your new module. A short overview of the generated parts can be found
in the [PDK documentation][1].
The README template below provides a starting point with details about what
information to include in your README.
## Table of Contents
1. [Description](#description)
1. [Setup - The basics of getting started with <%= name %>](#setup)
* [What <%= name %> affects](#what-<%= name %>-affects)
* [Setup requirements](#setup-requirements)
* [Beginning with <%= name %>](#beginning-with-<%= name %>)
1. [Usage - Configuration options and additional functionality](#usage)
1. [Limitations - OS compatibility, etc.](#limitations)
1. [Development - Guide for contributing to the module](#development)
## Description
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.
## Setup
### What <%= name %> affects **OPTIONAL**
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.
### Setup Requirements **OPTIONAL**
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.
### Beginning with <%= name %>
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.
## Usage
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.
## Reference
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][2] and [style guide][3].
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.
For example:
```
### `pet::cat`
#### Parameters
##### `meow`
Enables vocalization in your cat. Valid options: 'string'.
Default: 'medium-loud'.
```
## Limitations
In the Limitations section, list any incompatibilities, known issues, or other
warnings.
## Development
In the Development section, tell other users the ground rules for contributing
to your project and how they should submit their work.
## Release Notes/Contributors/Etc. **Optional**
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 `##` header.
[1]: https://puppet.com/docs/pdk/latest/pdk_generating_modules.html
[2]: https://puppet.com/docs/puppet/latest/puppet_strings.html
[3]: https://puppet.com/docs/puppet/latest/puppet_strings_style.html