homebloghow github labels streamline puppet module release process

How GitHub Labels streamline the Puppet Module release process

So how do GitHub Labels streamline the Puppet Module release process you ask? As many contributors may have noticed, there are a few GitHub labels that now exist across most of our supported modules in GitHub. If you have a module that is pdk-compliant, there is no reason why you couldn’t make use of this too! It is not limited to supported modules.

This article will help you learn how to make the most of GitHub labels during your Puppet Module development.

How the labels work with module development


These labels are used for two purposes. First one being a quick method of communication on the PR. If your PR has been labelled with a prefix of ‘needs’, it means that there is something that you need to do before we can consider merging your PR. These labels are as follows:

  • needs-docs
  • needs-rebase
  • needs-tests

When you make the changes required, according to the label that has been assigned, it will be one step closer to getting merged into the master branch.

The second and our main purpose of using labels is that we now automatically generate our changelog when we are releasing a module. We are using a tool called GitHub Changelog Generator. By adding the appropriate label this will select the category that your PR will appear under on the changelog entry. Each label will map to a section within the CHANGELOG.


Any PR labelled the maintenance label will not show in the changelog. This is because the change is minor and does not affect the codebase. Putting it into the CHANGELOG would not create any value for the end user.

Backwards incompatible

Changelog Section: Changed
Version bump: x
Release Type: Major

Anything with the backwards incompatible label will become an entry under the Changed section. This means that the PR includes backwards-incompatible API changes.


Changelog Section: Added
Version bump: y
Release Type: Minor

Anything with the feature label will become an entry under the Added section. This means that the PR has added functionality in a backwards-compatible manner.


Changelog Section: Fixes
Version bump: z
Release Type: Patch

Anything with the bug fix label will become an entry under the Fixed section. This means that the PR includes backwards-compatible bug fixes.

Here’s an example


In the above example it is apparent that this release includes both a feature and multiple bug fixes. The most important thing to notice is that there have been no backwards incompatible changes introduced.

Try it out with your Puppet Module development

Using Github Changelog Generator has started to increase the consistency and traceability between each release we make. Ensuring that any relevant changes will not miss out on an entry to the changelog. Adding labels is not limited to the Modules team, as usually you have created the PR, you will have a good understanding of what category your changes fit under.

If you feel comfortable feel free to add the appropriate label to your PR.

Don’t worry! If you forget to label a PR or don’t feel comfortable when the modules team generate the CHANGELOG, the unlabelled PR will show under an extra category called UNCATEGORIZED PRS; GO LABEL THEM. If the label is then added to the PR and the CHANGELOG regenerated it will appear under the category assigned to it depending on the label that has been applied.

For more information on versioning please check out semver.org.

To see an example of this implemented end to end and running live you can check out Top 4 Tips for Module Development. This talk was presented in Amsterdam at Puppetize live 2018 by myself and my colleague Helen Campbell.

Learn more