Running IntelliJ IDEA Inspections on Jenkins

IntelliJ IDEA today has the most advanced static Java code analyzer, which in its capabilities left far behind such "veterans" like Checkstyle and Spotbugs . Its many “inspections” check the code in various aspects, from the coding style to the characteristic bugs.

However, while analysis results are displayed only in the local interface of the developer IDE, they are of little use for the development process. Static analysis should be performed as the first step of the assembly pipeline, its results should determine quality gates, and the assembly should fail if quality gates are not passed. TeamCity CI is known to be integrated with IDEA. But even if you are not using TeamCity, you may well try to run IDEA inspections on any other CI server. I propose to see how this can be done using the IDEA Community Edition, Jenkins and Warnings NG plugin.

Step 1. Run the analysis in the container and get a report

Initially, the idea of ​​starting an IDE (desktop application!) Inside a CI system that does not have a graphical interface can seem dubious and very troublesome. Fortunately, IDEA developers have provided the ability to run code formatting and inspections from the command line. Moreover, to run IDEA in this mode, a graphics subsystem is not required and these tasks can be performed on servers with a text shell.

Inspections are launched using a script bin/inspect.shfrom the IDEA installation directory. As parameters are required:

• full path to the project (relative not supported)
• path to the .xml file with inspection settings (usually located inside the project in .idea / inspectionProfiles / Project_Default.xml),
• full path to the folder into which .xml files with reports on the analysis results will be added.

In addition, it is expected that

• the IDE will configure the path to the Java SDK, otherwise the analysis will not work. These settings are contained in the configuration file jdk.table.xmlin the IDEA global configuration folder. The global IDEA configuration itself lies by default in the user's home directory, but this location can be explicitly specified in the file idea.properties.
• the analyzed project should be a valid IDEA project, for which version control will have to commit some files that are usually ignored, namely:
  
  • .idea/inspectionProfiles/Project_Default.xml - analyzer settings, they will obviously be used when starting inspections in the container,
  • .idea/modules.xml - otherwise we get the error 'This project contains no modules',
  • .idea/misc.xml - otherwise we get the error 'The JDK is not configured properly for this project',
  • *.iml-файлы - otherwise, we get an error about a non-configured JDK in the module.

Although these files are usually included in .gitignore, they do not contain any information specific to the environment of a particular developer - unlike, for example, a file workspace.xmlwhere such information is contained, and therefore it is not necessary to commit it.

Itself begs a way to pack the JDK together with IDEA Community Edition in a container in a form ready to "set" the analyzed projects. We’ll select the appropriate base container, and here’s the Dockerfile we get:

FROM openkbs/ubuntu-bionic-jdk-mvn-py3
ARG INTELLIJ_VERSION="ideaIC-2019.1.1"
ARG INTELLIJ_IDE_TAR=${INTELLIJ_VERSION}.tar.gz
ENV IDEA_PROJECT_DIR="/var/project"
WORKDIR /opt
COPY jdk.table.xml /etc/idea/config/options/
RUN wget https://download-cf.jetbrains.com/idea/${INTELLIJ_IDE_TAR} && \
    tar xzf ${INTELLIJ_IDE_TAR} && \
    tar tzf ${INTELLIJ_IDE_TAR} | head -1 | sed -e 's/\/.*//' | xargs -I{} ln -s {} idea && \
    rm ${INTELLIJ_IDE_TAR} && \
    echo idea.config.path=/etc/idea/config >> idea/bin/idea.properties && \
    chmod -R 777 /etc/idea
CMD idea/bin/inspect.sh ${IDEA_PROJECT_DIR} ${IDEA_PROJECT_DIR}/.idea/inspectionProfiles/Project_Default.xml ${IDEA_PROJECT_DIR}/target/idea_inspections -v2

Using the option, idea.config.pathwe forced IDEA to search for its global configuration in the folder /etc/idea, because the user's home folder in the CI environment is an indeterminate thing and often completely absent.

This is how the file copied to the container looks jdk.table.xmlin which the paths to the OpenJDK installed inside the container are written (a similar file from your own directory with IDEA settings can be taken):

The finished image is available on the Docker Hub .

Before moving on, check the start of the IDEA analyzer in the container:

docker run --rm -v <путь/к/вашему/проекту>:/var/project inponomarev/intellij-idea-analyzer

The analysis should work out successfully, and numerous .xml files with analyzer reports should appear in the subfolder target / idea_inspections.

Now there is no longer any doubt that the IDEA can be run offline in any CI environment, and we move on to the second step.

Step 2. Display and analyze the report

Getting a report in the form of .xml files is half the battle, now you need to make it human-readable. And also its results should be used in quality gates - the logic of determining whether an accepted change passes or does not pass according to quality criteria.

This will help us Jenkins Warnings NG Plugin , which was released in January 2019. With its appearance, many individual plugins for working with the results of static analysis in Jenkins (CheckStyle, FindBugs, PMD, etc.) are now marked as obsolete.

The plugin consists of two parts:

• numerous analyzer message collectors (the full list includes all known analyzers from AcuCobol to ZPT Lint),
• a single viewer for all of them.

The list of what Warnings NG can analyze includes warnings from the Java compiler and warnings from the Maven runtime logs: although they are constantly in sight, they are seldom analyzed purposefully. IntelliJ IDEA reports are also included in the list of recognized formats.

Since the plugin is new, it initially interacts well with Jenkins Pipeline. The assembly step with his participation will look like this (we just tell the plug-in which report format we recognize and which files should be scanned):

stage ('Static analysis'){
    sh 'rm -rf target/idea_inspections'
    docker.image('inponomarev/intellij-idea-analyzer').inside {
       sh '/opt/idea/bin/inspect.sh $WORKSPACE $WORKSPACE/.idea/inspectionProfiles/Project_Default.xml $WORKSPACE/target/idea_inspections -v2'
    }
    recordIssues(
       tools: [ideaInspection(pattern: 'target/idea_inspections/*.xml')]
    )
}

The report interface looks like this:

Conveniently, this interface is universal for all recognized analyzers. It contains an interactive diagram of the distribution of finds by category and a graph of the dynamics of changes in the number of finds. In the grid at the bottom of the page, you can perform a quick search. The only thing that IDEA did not work correctly for the inspections was the ability to browse the code directly in Jenkins (although for other reports, such as Checkstyle, this plugin can do this beautifully). This seems to be an IDEA report parser bug to fix.

Among the capabilities of Warnings NG is the ability to aggregate finds from different sources in one report and program Quality Gates, including a ratchet for the reference assembly. Some Quality Gates programming documentation is available here - however, it is not complete, and you have to look at the source. On the other hand, for full control over what is happening, the “ratchet” can be implemented independently (see my previous post on this topic).

Conclusion

Before starting to prepare this material, I decided to search: did anyone already write on this topic in Habré? I only found a 2017 interview with lany where he says:

As far as I know, there is no integration with Jenkins or the maven plugin [...] In principle, any enthusiast could make friends IDEA Community Edition and Jenkins, many would benefit from this.

Well: two years later, we have Warnings NG Plugin, and finally this friendship has come true!