ProHoster > Blog > Administration > Starten von IntelliJ IDEA-Inspektionen auf Jenkins

Starten von IntelliJ IDEA-Inspektionen auf Jenkins

IntelliJ IDEA verfügt heute über den fortschrittlichsten statischen Java-Code-Analyzer, dessen Möglichkeiten die solcher "Veteranen" wie weit hinter sich gelassen haben. Checkstyle und Spotbugs. Ihre zahlreichen „Inspektionen“ überprüfen den Code in verschiedenen Aspekten, von Codierungsstil bis hin zu typischen Bugs.

Allerdings sind die Analyseergebnisse bisher nur im lokalen Interface der Entwickler-IDE sichtbar, was für den Entwicklungsprozess wenig Nutzen bringt. Statische Analyse muss durchgeführt werden als erster Schritt der Build-Pipeline, die Ergebnisse sollten die Quality Gates bestimmen, und der Build sollte fehlschlagen, wenn die Quality Gates nicht erfüllt sind. Es ist bekannt, dass TeamCity CI mit IDE integriert ist. Aber selbst wenn Sie TeamCity nicht verwenden, können Sie versuchen, die Inspektionen der IDE auf jedem anderen CI-Server auszuführen. Lassen Sie uns sehen, wie das geht, indem wir die IDEA Community Edition, Jenkins und das Warnings NG-Plugin verwenden.

Schritt 1. Wir führen die Analyse in einem Container aus und erhalten einen Bericht

Anfangs kann es fragwürdig und sehr umständlich erscheinen, eine IDE (Desktop-Anwendung!) innerhalb eines CI-Systems ohne grafische Benutzeroberfläche auszuführen. Glücklicherweise haben die Entwickler der IDE die Möglichkeit geschaffen, Code-Formatierung und Inspektionen aus der Kommandozeile auszuführen. Darüber hinaus ist für den Betrieb der IDE in diesem Modus keine grafische Subsystem erforderlich, und diese Aufgaben können auf Servern mit textbasierten Shells durchgeführt werden.

Die Inspektionen werden über das Skript bin/inspect.sh aus dem Installationsverzeichnis der IDE gestartet. Als Parameter werden benötigt:

  • der vollständige Pfad zum Projekt (relative Pfade werden nicht unterstützt),
  • der Pfad zur .xml-Datei mit den Inspektionseinstellungen (befindet sich normalerweise innerhalb des Projekts in .idea/inspectionProfiles/Project_Default.xml),
  • der vollständige Pfad zum Ordner, in dem die .xml-Dateien mit den Analyseergebnissen gespeichert werden sollen.

Außerdem wird erwartet, dass

  • der Pfad zum Java SDK in der IDE konfiguriert ist, andernfalls funktioniert die Analyse nicht. Diese Einstellungen befinden sich in der Konfigurationsdatei jdk.table.xml im Ordner der globalen Konfiguration der IDE. Die globale Konfiguration der IDE befindet sich standardmäßig im Heimatverzeichnis des Benutzers, aber dieser Speicherort kann explizit angegeben werden in der Datei idea.properties.
  • das analysierte Projekt muss ein gültiges IDE-Projekt sein, weshalb einige Dateien, die normalerweise ignoriert werden, in die Versionskontrolle eincommittet werden müssen, nämlich:
    • .idea/inspectionProfiles/Project_Default.xml — die Einstellungen des Analysewerkzeugs, die bei der Ausführung der Inspektionen im Container eindeutig verwendet werden,
    • .idea/modules.xml — andernfalls erhalten wir den Fehler ‚Dieses Projekt enthält keine Module‘,
    • .idea/misc.xml — andernfalls erhalten wir den Fehler 'Das JDK ist für dieses Projekt nicht richtig konfiguriert',
    • *.iml-Dateien — andernfalls erhalten wir einen Fehler bezüglich eines nicht konfigurierten JDK im Modul.

Obwohl diese Dateien normalerweise enthalten sind, .gitignore, enthalten sie keine spezifischen Informationen für die Umgebung eines bestimmten Entwicklers – im Gegensatz zu beispielsweise der Datei workspace.xml, wo solche Informationen tatsächlich enthalten sind, und daher sollte man sie nicht einpflegen.

Es liegt nahe, eine Lösung zu finden, das JDK zusammen mit der IDEA Community Edition in einem Container zu verpacken, der bereit ist, auf die zu analysierenden Projekte 'angewendet' zu werden. Wählen wir einen geeigneten Basiscontainer, und so ergibt sich folgender Dockerfile:

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

Mit der Option idea.config.path haben wir IDEA dazu gebracht, ihre globale Konfiguration im Ordner /etc/idea, zu suchen, da das Heimatverzeichnis des Benutzers in CI-Arbeitsbedingungen unbestimmt und oft überhaupt nicht vorhanden ist.

So sieht die in den Container kopierte Datei aus jdk.table.xml, in der die Pfade zur innerhalb des Containers installierten OpenJDK angegeben sind (als Vorlage kann eine ähnliche Datei aus Ihrem eigenen Verzeichnis mit IDE-Einstellungen verwendet werden):

jdk.table.xml

Bild in fertiger Form auf Docker Hub verfügbar.

Bevor wir weitermachen, überprüfen wir den Start des IDEA-Analyzers im Container:

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

Die Analyse sollte erfolgreich durchlaufen und in dem Unterverzeichnis target/idea_inspections sollten zahlreiche .xml-Dateien mit Berichten des Analyzers erscheinen.

Jetzt gibt es keinen Zweifel mehr daran, dass der IDEA-Analyzer im Offline-Modus in jeder CI-Umgebung ausgeführt werden kann, und wir gehen zu Schritt zwei über.

Schritt 2. Bericht anzeigen und analysieren

Einen Bericht im .xml-Format zu erhalten, ist nur die halbe Miete; jetzt muss er leserlich gemacht werden. Außerdem müssen die Ergebnisse in den Quality Gates verwendet werden – einer Logik zur Bestimmung, ob die eingehenden Änderungen den Qualitätskriterien entsprechen oder nicht.

Dabei hilft uns Jenkins Warnings NG Plugin, dessen Veröffentlichung im Januar 2019 erfolgte. Mit seinem Erscheinen wurden viele einzelne Plugins zur Verarbeitung der Ergebnisse statischer Analysen in Jenkins (CheckStyle, FindBugs, PMD usw.) nun als veraltet (obsolete) gekennzeichnet.

Das Plugin besteht aus zwei Teilen:

  • zahlreichen Nachrichtensammlern von Analysewerkzeugen (vollständige Liste die alle bekannten Analysewerkzeuge von AcuCobol bis ZPT Lint umfasst,
  • und einem einheitlichen Berichtszusammensteller für alle.

Im Bereich dessen, was Warnings NG analysieren kann, sind unter anderem die Warnungen des Java-Compilers und Warnungen aus Maven-Ausführungsprotokollen enthalten: Obwohl diese ständig sichtbar sind, werden sie selten gezielt analysiert. Die Berichte von IntelliJ IDEA gehören ebenfalls zu den erkannten Formaten.

Da das Plugin neu ist, funktioniert es von Anfang an gut mit Jenkins Pipeline. Der Build-Schritt mit ihm wird folgendermaßen aussehen (wir sagen einfach dem Plugin, welches Berichtformat erkannt werden soll und welche Dateien durchsucht werden sollen):

stage ('Statische Analyse'){
    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')]
    )
}

Die Berichtsschnittstelle sieht folgendermaßen aus:

Starten von IntelliJ IDEA-Inspektionen auf Jenkins

Es ist praktisch, dass diese Schnittstelle für alle erkannten Analysewerkzeuge einheitlich ist. Sie enthält ein interaktives Diagramm zur Verteilung der Funde nach Kategorien und ein Diagramm, das die Dynamik der Anzahl der Funde abbildet. Im Grid unten auf der Seite kann eine schnelle Suche durchgeführt werden. Das Einzige, was bei den Inspektionen von IDEA nicht richtig funktioniert hat, ist die Möglichkeit, den Code direkt in Jenkins zu durchsuchen (obwohl dieser Plugin bei anderen Berichten, wie z.B. Checkstyle, dies schön machen kann). Es scheint ein Fehler im Parser der IDEA-Berichte zu sein, den es zu beheben gilt.

Zu den Möglichkeiten von Warnings NG gehört die Möglichkeit, Funde aus verschiedenen Quellen in einem Bericht zu aggregieren und Quality Gates zu programmieren, einschließlich eines „Kollapses“ auf Basis des Referenz-Builds. Einige Dokumentationen zur Programmierung von Quality Gates sind verfügbar. hier — allerdings ist sie nicht vollständig, und man muss die Quelltexte betrachten. Andererseits kann man für eine vollständige Kontrolle über das Geschehen den 'Ratschlag' auch selbst umsetzen (siehe meinen vorherigen Beitrag zu diesem Thema).

Fazit

Bevor ich mit der Vorbereitung dieses Materials begann, wollte ich nachsehen, ob bereits jemand zu diesem Thema auf Habré geschrieben hatte. Ich fand nur ein Interview aus dem Jahr 2017 c lany, in dem er sagt:

Soweit ich weiß, gibt es keine Integration mit Jenkins oder einem Maven-Plugin […] Im Prinzip könnte jeder Enthusiast IDEA Community Edition und Jenkins miteinander verbinden, viele würden davon nur profitieren.

Was ist also passiert: Nach zwei Jahren haben wir das Warnings NG Plugin, und endlich ist diese Freundschaft verwirklicht worden!

Quelle: habr.com

60GB SSD 8Gb DDR4