Skip to content


Switch branches/tags

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?

Latest commit


Git stats


Failed to load latest commit information.
Latest commit message
Commit time

SonarQube Puppet Plugin

Build Status Gitter Coverage Status GitHub release GitHub license Technical debt ratio Quality Gate


This plugin enables analysis of Puppet code. It comes with more than 60 rules spanning from style checks (i.e. All arrows in attribute/value list should be aligned) to detection of potential bugs (i.e. Duplicated parameters should be removed). This is currently written to support the grammar for Puppet 3.8, support for the future parser is not currently available.


Getting Started in Less Than Two Minutes

To get started in less than two minutes, you can download the package at and follow the instructions in the README file.

Getting Started

To run an analysis of your Puppet project, we recommend to use SonarQube Runner. There are two strategies:

  1. Analyze each of your modules separately
  2. Analyze all your modules at once

Analyze each of your modules separately

It means that one SonarQube project is created for each Puppet module. Let's take the Puppet Labs Apache module at as an example.

  • Clone this project (let's say in the /home/user/puppet directory)
  • Add a file to the /home/user/puppet directory with the following content:
sonar.projectName=Puppet Labs Apache Module
  • Run sonar-runner from /home/user/puppet

Analyze all your modules at once

It means that one single SonarQube project is created for all the Puppet modules.

  • Retrieve the source code of your modules with your favorite tool (such as r10k), let's say in /home/user/puppet. The tree structure should be the following:
  • Add a file to the /home/user/puppet directory with the following content:
sonar.projectName=My Puppet Code Base
  • Run sonar-runner from /home/user/puppet

Which strategy to choose?

The first strategy easily allows you to automate a SonarQube analysis of a module each time a developer pushes some code to the VCS. By providing a quick feedback to developers, you can ensure that quality flaws are quickly fixed.

The second strategy provides a quality overview of your entire Puppet Code Base and how it evolves overtime. Moreover, analyzing your whole code base at once allows you to benefit from more advanced cross-module checks (such as the autoloader layout rule).

We recommend you to apply both strategies to get all the benefits.


The Puppet terms do not always match with the standard SonarQube metrics. Here's the list of slight differences:

  • Classes = Number of classes + Number of defines
  • Functions = Number of resources (including default resource and resource override)
  • Complexity is increased by one for each: class, define, resource instance, resource default statement, resource override, if, elsif, unless, selector match, case match, and, or.

Extending Coding Rules using XPath

New coding rules can be added using XPath. See the related documentation. To navigate the AST, download the SSLR Puppet Toolkit.