Jenkins - Code Analysis

Jenkins - Static Code Analysis

Static code analysis tools examine source code without executing it, identifying potential bugs, code style violations, security vulnerabilities, and adherence to best practices. Integrating these tools into your Jenkins pipeline provides early feedback on code quality.

The Modern Approach: Warnings Next Generation Plugin

While older Jenkins setups used individual plugins for each analysis tool (Checkstyle Plugin, PMD Plugin, FindBugs Plugin, etc.), the modern and recommended approach is to use the ‘Warnings Next Generation’ plugin (ID: warnings-ng).

This plugin provides a unified way to parse report files from a vast number of static analysis tools and display the results consistently in Jenkins.

Integration Steps

Step 1: Install the ‘Warnings Next Generation’ Plugin.

• Go to Manage Jenkins → Plugins → Available Plugins.
• Search for ‘Warnings Next Generation’.
• Install the plugin and restart Jenkins if prompted.

Step 2: Configure Your Build to Generate Reports.

• Integrate static analysis tools into your build process using build tool plugins (Maven, Gradle, etc.) or run them as standalone commands.
• Configure the tools to generate report files in a supported format (often XML or JSON).
• Common Java Tools & Plugins:
• • Checkstyle: maven-checkstyle-plugin, Gradle checkstyle plugin.
• • PMD: maven-pmd-plugin, Gradle pmd plugin.
• • SpotBugs (successor to FindBugs): spotbugs-maven-plugin, Gradle spotbugs plugin.
• Common JavaScript Tools:
• • ESLint: Run via npm scripts, configure output format (e.g., checkstyle XML).
• Other Tools: The Warnings NG plugin supports dozens of tools across many languages. Check its documentation for the full list and expected report formats: https://plugins.jenkins.io/warnings-ng/

Step 3: Publish Reports in Jenkins Pipeline.

• Use the recordIssues step provided by the Warnings NG plugin, typically within the post section of your Jenkinsfile or after the build/analysis commands run.
• Configure the tools parameter, specifying the parser for each tool and the pattern to locate its report file(s).

Example: Declarative Pipeline with Maven (Checkstyle, PMD, SpotBugs)

Assume your pom.xml is configured with the respective Maven plugins to run during the verify phase and generate XML reports in the target directory.

pipeline {
    agent any
    tools {
        maven 'Maven 3.8'
        jdk 'JDK 11'
    }
    stages {
        stage('Checkout') {
            steps {
                git url: 'your-repo-url', branch: 'main'
            }
        }
        stage('Build and Analyze') {
            steps {
                // 'verify' phase typically runs Checkstyle, PMD, SpotBugs if configured
                sh 'mvn clean verify'
            }
        }
    }
    post {
        always {
            // Always record issues found
            recordIssues(
                // Aggregate results from multiple tools
                aggregatingResults: true,
                // Define the tools and their report locations
                tools: [
                    checkStyle(pattern: '**/target/checkstyle-result.xml'),
                    pmdParser(id: 'pmd', name: 'PMD', pattern: '**/target/pmd.xml'), // Explicit ID/Name optional
                    spotbugs(pattern: '**/target/spotbugsXml.xml')
                ]
            )

            // Also publish test results, etc.
            junit '**/target/surefire-reports/*.xml'
        }
    }
}

Viewing Analysis Results

After the recordIssues step runs:

• A ‘Warnings’ link (or links for each tool if not aggregated) appears on the build page sidebar.
• Clicking the link shows:
• • A trend graph of the number of warnings over time.
• • Summary counts (total warnings, new warnings, fixed warnings).
• • Breakdown by severity, category, module, package, etc.
• • Detailed views of each issue, often linking directly to the affected source code line within Jenkins (if source code scanning is enabled in the step).
• The build status can be influenced by the number or severity of warnings (e.g., set build to UNSTABLE if new high-priority warnings appear). This is configurable within the recordIssues step (failOnError, unstableOnError, quality gates).

Integrating static analysis provides objective metrics on code quality and helps enforce coding standards automatically within your CI/CD process.