We launch inspections IntelliJ IDEA on Jenkins

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

However, while the analysis results are displayed only in the developer's local IDE interface, they have little use for the development process. Static analysis should be performed as the first step of the assembly line, its results should determine the quality gates, and the assembly should fail if quality gates is not passed. It is known that TeamCity CI is 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 the report

At first, the idea to launch an IDE (desktop application!) Within a CI system that does not have a graphical interface may 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 does not require a graphics subsystem and these tasks can be performed on servers with a text shell.

Inspections are launched using the bin/inspect.sh from the IDEA installation directory. As parameters are required:

• full path to the project (relative is not supported),
• The path to the .xml file with the inspection settings (usually located inside the project in .idea / inspectionProfiles / Project_Default.xml),
• full path to the folder where the .xml files with the analysis results reports 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 jdk.table.xml configuration file in the global configuration folder IDEA. The IDEA global configuration itself is in the user's home directory by default, but this location can be explicitly set in the idea.properties file.
• The analyzed project must be a valid IDEA project, for which you will have to commit some files to version control, which are usually ignored, namely:
  
  • .idea/inspectionProfiles/Project_Default.xml - analyzer settings, they will obviously be used when starting inspections in a 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 not configured JDK in the module.

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

Itself suggests a way to pack the JDK with IDEA Community Edition into a container in the form ready for “setting off” on the analyzed projects. Choose a suitable base container, and this is how we get Dockerfile:

 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 idea.config.path option idea.config.path we forced IDEA to search for its global configuration in the /etc/idea folder, since the user's home folder in CI is an indefinite thing and often completely missing.

This is how the jdk.table.xml file copied to the container looks like, in which the paths to the OpenJDK installed inside the container are specified (a similar file from your own directory with IDEA settings can be used as a basis):

 <application> <component name="ProjectJdkTable"> <jdk version="2"> <name value="1.8" /> <type value="JavaSDK" /> <version value="1.8" /> <homePath value="/usr/java" /> <roots> <annotationsPath> <root type="composite"> <root url="jar://$APPLICATION_HOME_DIR$/lib/jdkAnnotations.jar!/" type="simple" /> </root> </annotationsPath> <classPath> <root type="composite"> <root url="jar:///usr/java/jre/lib/charsets.jar!/" type="simple" /> <root url="jar:///usr/java/jre/lib/deploy.jar!/" type="simple" /> <root url="jar:///usr/java/jre/lib/ext/access-bridge-64.jar!/" type="simple" /> <root url="jar:///usr/java/jre/lib/ext/cldrdata.jar!/" type="simple" /> <root url="jar:///usr/java/jre/lib/ext/dnsns.jar!/" type="simple" /> <root url="jar:///usr/java/jre/lib/ext/jaccess.jar!/" type="simple" /> <root url="jar:///usr/java/jre/lib/ext/jfxrt.jar!/" type="simple" /> <root url="jar:///usr/java/jre/lib/ext/localedata.jar!/" type="simple" /> <root url="jar:///usr/java/jre/lib/ext/nashorn.jar!/" type="simple" /> <root url="jar:///usr/java/jre/lib/ext/sunec.jar!/" type="simple" /> <root url="jar:///usr/java/jre/lib/ext/sunjce_provider.jar!/" type="simple" /> <root url="jar:///usr/java/jre/lib/ext/sunmscapi.jar!/" type="simple" /> <root url="jar:///usr/java/jre/lib/ext/sunpkcs11.jar!/" type="simple" /> <root url="jar:///usr/java/jre/lib/ext/zipfs.jar!/" type="simple" /> <root url="jar:///usr/java/jre/lib/javaws.jar!/" type="simple" /> <root url="jar:///usr/java/jre/lib/jce.jar!/" type="simple" /> <root url="jar:///usr/java/jre/lib/jfr.jar!/" type="simple" /> <root url="jar:///usr/java/jre/lib/jfxswt.jar!/" type="simple" /> <root url="jar:///usr/java/jre/lib/jsse.jar!/" type="simple" /> <root url="jar:///usr/java/jre/lib/management-agent.jar!/" type="simple" /> <root url="jar:///usr/java/jre/lib/plugin.jar!/" type="simple" /> <root url="jar:///usr/java/jre/lib/resources.jar!/" type="simple" /> <root url="jar:///usr/java/jre/lib/rt.jar!/" type="simple" /> </root> </classPath> </roots> <additional /> </jdk> </component> </application> 

A finished image is available on the Docker Hub .

Before moving further, let's check the launch of the IDEA analyzer in the container:

 docker run --rm -v <///>:/var/project inponomarev/intellij-idea-analyzer 

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

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

Step 2. Display and analyze the report

To receive the report in the form of .xml-files is half the battle, now it needs to be made human-readable. And also its results should be used in quality gates - the logic of determining whether the accepted change passes or does not pass according to the quality criteria.

Jenkins Warnings NG Plugin , which was released in January 2019, will help us in this. With its appearance, many separate plugins for working with static analysis results in Jenkins (CheckStyle, FindBugs, PMD, etc.) are now marked 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.

In the list of what Warnings NG can analyze, there are also Java compiler warnings and warnings from the Maven execution logs: although they are constantly visible, they are rarely deliberately analyzed. IntelliJ IDEA reports are also included in the list of recognizable formats.

Since the plugin is new, it initially interacts well with Jenkins Pipeline. The assembly step with its participation will look like this (we just tell the plugin 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 chart of the distribution of finds by categories 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 did not work correctly for IDEA bakes is the ability to browse the code directly in Jenkins (although for other reports, such as Checkstyle, this plugin can do this beautifully). It looks like this is a bug of IDEA report parser that needs to be fixed.

Among the possibilities of Warnings NG is the ability to aggregate finds from different sources in one report and program Quality Gates, including the “ratchet” on the reference assembly. Some of the Quality Gates programming documentation is available here - however, it is not complete, and you have to look at the sources. On the other hand, for complete 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: but did anyone write on this topic on Habré already? I found only a 2017 interview with lany , where he says:

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

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