Skip to content
Branch: master
Find file Copy path
Find file Copy path
2 contributors

Users who have contributed to this file

@uhafner @FlashSheridan
120 lines (92 sloc) 4.35 KB

Providing support for a custom static analysis tool

The most flexible way to add a new static analysis tool to the Warnings Next Generation plugin is to provide a new custom plugin that contains a Java implementation of the tool.

Create a plugin

The plugin should depend on Jenkins plugin parent pom and on the Warnings Next Generation plugin.

<project xmlns="" xmlns:xsi="" xsi:schemaLocation="">

    <relativePath />

  <name>[Your Plugin Name]</name>


Create a parser class

If your tool must parse a report file in order to produce the issues, you need to write a corresponding parser. Otherwise you can continue with section registering your tool. Each custom tool requires a parser that will be instantiated to scan the console log (or a report file). The parser must derive from the abstract class IssueParser or one of its child classes. The following classes can be used as base class:

  • IssueParser: parses a report file. You have under full control on how to access the report using the ReaderFactory.
  • LookaheadParser: parses all lines of a report one by one with a regular expression. If the regular expression matches, then you can create a new Issue based on the matching groups. You can also consume additional lines of the log if required.
  • RegexpLineParser: Simplified version of LookaheadParser, that does not allow to consume additional lines.

Please have a look at one of the existing parsers in order to see how to use these base classes.

Register the tool

In order to get picked up by the warnings plugin your parser must be registered as an extension. This is achieved by extending from the base class Tool and registering it using the annotation @Extension at your associated Descriptor class. Typically you do this in Jenkins by adding the descriptor as a static nested class of your Tool class.

Since most of the static analysis tools are based on a report file, the more specific base class ReportScanningTool has been provided that should be used in this case - this base class provides already support for adding a report pattern and encoding property in the user interface.

Here is an example that can be used as a starting point.

package io.jenkins.plugins.analysis.warnings;

import javax.annotation.Nonnull;

import org.kohsuke.stapler.DataBoundConstructor;

import io.jenkins.plugins.analysis.core.model.ReportScanningTool;

import hudson.Extension;

 * Provides a parser and customized messages for your tool.
public class YourTool extends ReportScanningTool {
    private static final long serialVersionUID = 1L;
    static final String ID = "your-id";

    /** Creates a new instance of {@link YourTool}. */
    public YourTool() {
        // empty constructor required for stapler

    public YourParserClass createParser() {
        return new YourParserClass();

    /** Descriptor for this static analysis tool. */
    public static class Descriptor extends ReportScanningToolDescriptor {
        /** Creates the descriptor instance. */
        public Descriptor() {

        public String getDisplayName() {
            return "Your parser name";

Packaging the plugin

You can create a HPI of your plugin by calling mvn clean install. For more details on Jenkins plugin development please see wiki or homepage.

You can’t perform that action at this time.