SonarQube plugin for Puppet code.
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Failed to load latest commit information.
gradle
puppet-checks
puppet-squid
sonar-puppet-plugin
sslr-puppet-toolkit #271 move to sonarqube 5.6 LTS May 15, 2017
.dockerignore
.gitignore
.travis.yml
Dockerfile
LICENSE
README.md
build.gradle
gradlew
gradlew.bat
settings.gradle

README.md

SonarQube Puppet Plugin

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

Description

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.

Requirements

Getting Started in Less Than Two Minutes

To get started in less than two minutes, you can download the package at https://github.com/racodond/package-test-sonarqube-puppet 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 https://github.com/puppetlabs/puppetlabs-apache as an example.

  • Clone this project (let's say in the /home/user/puppet directory)
  • Add a sonar-project.properties file to the /home/user/puppet directory with the following content:
sonar.projectKey=puppetlabs-apache
sonar.projectName=Puppet Labs Apache Module
sonar.sources=puppetlabs-apache
sonar.projectVersion=1.4.1
  • 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:
/home/user/puppet
   |--modules
      |--mymodule1
         |--manifests
            |--init.pp
            |--...
      |--mymodule2
         |--manifests
            |--init.pp
            |--...
  • Add a sonar-project.properties file to the /home/user/puppet directory with the following content:
sonar.projectKey=my-puppet-code-base
sonar.projectName=My Puppet Code Base
sonar.sources=modules
sonar.projectVersion=1.0
  • 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.

Metrics

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.