@atomist/sdm-pack-sonarqube NPM

@atomist/sdm-pack-sonarqube

Extension Pack for an Atomist SDM to integrate SonarQube.

Usage

This SDM pack enables you to scan your projects using SonarQube/SonarCloud. By default, the pack will fail your SDM goals if the scan does not pass your assigned quality gate (this behavior is configurable, see below). There are two scanner types available. The first, is the sonar-scanner utilty that can be used by any language. However, this scanner does require that you supply some configuration to the scanner in the form of a sonar-project.properties file (more details here). Alternatively, if you are using Maven projects this pack will automatically use the Maven integrated Sonar plugin which does not require configuration in your project (the POM is used to extract the required details).

Prereq

If you are working on projects that do not use Maven, you must install the Sonar Scanner utility. See instructions here

Setup

First install the dependency in your SDM project

$ npm install @atomist/sdm-pack-sonarqube

Install the support

import { SonarQubeSupport } from "@atomist/sdm-pack-sonarqube";
// [...]
const codeInspection = new AutoCodeInspection();
sdm.addExtensionPacks(
    sonarQubeSupport({
        ...sdm.configuration.sdm.sonar,
        inspectGoal: codeInspection,
    }),
);

Note: Depending on the language you are using you may need to include additional listeners on your inspection goals. For example, to run the Sonar scanner against a NodeJS project you must first execute a npm install. To accomplish this you can add the NPM listner from sdm-pack-node.
const codeInspection = new AutoCodeInspection()
       .withProjectListener(NodeModulesProjectListener);

Add configuration to your client configuration

"sonar": {
    "enabled": true,
    "url": "<your sonarqube url>",
    "org": "<your sonarqube org>",
    "token": "<your sonarqube token>"
}

Optional configurations

All of the configuration options below should be added to the sonar section of your config

Global options
- interval: How quickly should we poll to see if a Sonar scan has completed? Default is 10000ms (10 seconds). Value must be supplied in ms.
- warnOnSkipped: Should we publish a notice when some aspects of the quality gate are being ignored/skipped. This is typically the case when the update size is smaller then the required size. (Valid Values true/false, default behavior is true)
- sonarScannerPath: Path to the sonar-scanner utility within your SDM. This is not required if the command is within your path.
- sonarScannerArgs: Array of strings that should be passed to the Sonar scanner (sonar-scanner utility). Optional. This configuration item allows you to supply additional items, if required.
- mvnSonarArgs: Array of strings that should be passed to the Maven based Sonar scanner. Optional. This configuration item allows you to supply additional items, if required.
Default Review Listener Configuration
- useDefaultListener: Should we use the default Sonar review listener? By default this listener will display Quality gate results, the link to the analysis in the UI, as well as fail SDM goals if the quality gate did not pass. (Valid values, true/false. Default behavior is true.)
- failOnMissingViableConfig: Should we fail code inspection goal if there is no way to determine how to run a Sonar scan? This would be the case where it's not a Maven project and is missing a sonar-project.properties file. If enabled, this will fail the code inspection goal and raise an error message to your chat platform. (Valid values, true/false. Default behavior is true.)
- warnOnMissingViableConfig: Should we issue a warning if there is no way to determine how to run a Sonar scan? This would be the case where it's not a Maven project and is missing a sonar-project.properties file. If enabled, this will issue a warning in the Chat channel connected to this project, but your goals will not be failed. Will only execute if failOnMissingViableConfig is set to false. (Valid values, true/false. Default behavior is true.)

Support

General support questions should be discussed in the #support channel on our community Slack team at atomist-community.slack.com.

If you find a problem, please create an issue.

Development

You will need to install node to build and test this project.

To run tests, define a GITHUB_TOKEN to any valid token that has repo access. The tests will create and delete repositories.

Define GITHUB_VISIBILITY=public if you want these to be public; default is private. You'll get a 422 response from repo creation if you don't pay for private repos.

Build and Test

Command	Reason
`npm install`	install all the required packages
`npm run build`	lint, compile, and test
`npm run lint`	run tslint against the TypeScript
`npm run compile`	compile all TypeScript into JavaScript
`npm test`	run tests and ensure everything is working
`npm run clean`	remove stray compiled JavaScript files and build directory

Release

To create a new release of the project, update the version in package.json and then push a tag for the version. The version must be of the form M.N.P where M, N, and P are integers that form the next appropriate semantic version for release. The version in the package.json must be the same as the tag. For example:

$ npm version 1.2.3
$ git tag -a -m 'The ABC release' 1.2.3
$ git push origin 1.2.3

The Travis CI build (see badge at the top of this page) will publish the NPM module and automatically create a GitHub release using the tag name for the release and the comment provided on the annotated tag as the contents of the release notes.