README.md

   1 # stringstest
   2
   3 Welcome to your new module. A short overview of the generated parts can be found
   4 in the [PDK documentation][1].
   5
   6 The README template below provides a starting point with details about what
   7 information to include in your README.
   8
   9 ## Table of Contents
  10
  11 1. [Description](#description)
  12 1. [Setup - The basics of getting started with stringstest](#setup)
  13     * [What stringstest affects](#what-stringstest-affects)
  14     * [Setup requirements](#setup-requirements)
  15     * [Beginning with stringstest](#beginning-with-stringstest)
  16 1. [Usage - Configuration options and additional functionality](#usage)
  17 1. [Limitations - OS compatibility, etc.](#limitations)
  18 1. [Development - Guide for contributing to the module](#development)
  19
  20 ## Description
  21
  22 Briefly tell users why they might want to use your module. Explain what your
  23 module does and what kind of problems users can solve with it.
  24
  25 This should be a fairly short description helps the user decide if your module
  26 is what they want.
  27
  28 ## Setup
  29
  30 ### What stringstest affects **OPTIONAL**
  31
  32 If it's obvious what your module touches, you can skip this section. For
  33 example, folks can probably figure out that your mysql_instance module affects
  34 their MySQL instances.
  35
  36 If there's more that they should know about, though, this is the place to
  37 mention:
  38
  39 * Files, packages, services, or operations that the module will alter, impact,
  40   or execute.
  41 * Dependencies that your module automatically installs.
  42 * Warnings or other important notices.
  43
  44 ### Setup Requirements **OPTIONAL**
  45
  46 If your module requires anything extra before setting up (pluginsync enabled,
  47 another module, etc.), mention it here.
  48
  49 If your most recent release breaks compatibility or requires particular steps
  50 for upgrading, you might want to include an additional "Upgrading" section here.
  51
  52 ### Beginning with stringstest
  53
  54 The very basic steps needed for a user to get the module up and running. This
  55 can include setup steps, if necessary, or it can be an example of the most basic
  56 use of the module.
  57
  58 ## Usage
  59
  60 Include usage examples for common use cases in the **Usage** section. Show your
  61 users how to use your module to solve problems, and be sure to include code
  62 examples. Include three to five examples of the most important or common tasks a
  63 user can accomplish with your module. Show users how to accomplish more complex
  64 tasks that involve different types, classes, and functions working in tandem.
  65
  66 ## Reference
  67
  68 This section is deprecated. Instead, add reference information to your code as
  69 Puppet Strings comments, and then use Strings to generate a REFERENCE.md in your
  70 module. For details on how to add code comments and generate documentation with
  71 Strings, see the [Puppet Strings documentation][2] and [style guide][3].
  72
  73 If you aren't ready to use Strings yet, manually create a REFERENCE.md in the
  74 root of your module directory and list out each of your module's classes,
  75 defined types, facts, functions, Puppet tasks, task plans, and resource types
  76 and providers, along with the parameters for each.
  77
  78 For each element (class, defined type, function, and so on), list:
  79
  80 * The data type, if applicable.
  81 * A description of what the element does.
  82 * Valid values, if the data type doesn't make it obvious.
  83 * Default value, if any.
  84
  85 For example:
  86
  87 ```
  88 ### `pet::cat`
  89
  90 #### Parameters
  91
  92 ##### `meow`
  93
  94 Enables vocalization in your cat. Valid options: 'string'.
  95
  96 Default: 'medium-loud'.
  97 ```
  98
  99 ## Limitations
 100
 101 In the Limitations section, list any incompatibilities, known issues, or other
 102 warnings.
 103
 104 ## Development
 105
 106 In the Development section, tell other users the ground rules for contributing
 107 to your project and how they should submit their work.
 108
 109 ## Release Notes/Contributors/Etc. **Optional**
 110
 111 If you aren't using changelog, put your release notes here (though you should
 112 consider using changelog). You can also add any additional sections you feel are
 113 necessary or important to include here. Please use the `##` header.
 114
 115 [1]: https://puppet.com/docs/pdk/latest/pdk_generating_modules.html
 116 [2]: https://puppet.com/docs/puppet/latest/puppet_strings.html
 117 [3]: https://puppet.com/docs/puppet/latest/puppet_strings_style.html