IntelliJ IDEA bietet heute den fortschrittlichsten statischen Java-Code-Analyzer, der traditionelle "Urväter" wie und weit hinter sich gelassen hat. Ihre zahlreichen „Inspektionen“ überprüfen den Code in verschiedenen Aspekten, von der Programmierqualität bis zu typischen Fehlern.
Allerdings werden die Analyseergebnisse derzeit nur in der lokalen IDE-Oberfläche des Entwicklers angezeigt, was für den Entwicklungsprozess kaum hilfreich ist. Der statische Code-Analyse Als ersten Schritt im Build-Prozess sollten die Ergebnisse von Quality Gates bestimmt werden, und der Build sollte fehlschlagen, wenn die Quality Gates nicht bestanden werden. Es ist bekannt, dass TeamCity CI mit IDEA integriert ist. Selbst wenn Sie TeamCity nicht verwenden, können Sie dennoch versuchen, die Inspektionen von IDEA in jedem anderen CI-Server auszuführen. Lassen Sie uns ansehen, wie dies mit der IDEA Community Edition, Jenkins und dem Warnings NG-Plugin umgesetzt werden kann.
Schritt 1: Wir starten die Analyse in einem Container und erhalten einen Bericht.
Zunächst mag die Idee, eine IDE (Desktop-Anwendung!) innerhalb eines CI-Systems ohne grafische Benutzeroberfläche zu betreiben, fragwürdig und sehr aufwendig erscheinen. Glücklicherweise haben die Entwickler von IDEA eine Möglichkeit bereitgestellt, um und über die Kommandozeile auszuführen. Dabei ist für den Betrieb von IDEA in diesem Modus keine grafische Subsystem erforderlich, und diese Aufgaben können auf Servern mit Textoberfläche durchgeführt werden.
Die Ausführung der Inspektionen erfolgt mit einem Skript bin/inspect.sh aus dem Installationsverzeichnis von IDEA. Als Parameter sind erforderlich:
- der vollständige Pfad zum Projekt (relative Pfade werden nicht unterstützt),
- der Pfad zur .xml-Datei mit den Inspektionskonfigurationen (die sich normalerweise im Projektverzeichnis unter .idea/inspectionProfiles/Project_Default.xml befindet),
- und der vollständige Pfad zum Ordner, in dem die .xml-Dateien mit den Analyseberichten abgelegt werden sollen.
Darüber hinaus wird erwartet, dass
- der Pfad zum Java SDK in der IDE konfiguriert ist, da die Analyse sonst nicht funktioniert. Diese Einstellungen sind in der Konfigurationsdatei
jdk.table.xmlim Ordner der globalen Konfiguration von IDEA enthalten. Die globale Konfiguration von IDEA befindet sich standardmäßig im Home-Verzeichnis des Nutzers, aber dieser Speicherort in der Dateiidea.properties. - Das zu analysierende Projekt muss ein gültiges IDEA-Projekt sein, wofür einige Dateien, die normalerweise ignoriert werden, in die Versionskontrolle übernommen werden müssen, nämlich:
.idea/inspectionProfiles/Project_Default.xml— die Einstellungen des Analysators, die beim Start 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 korrekt konfiguriert’,*.iml-Dateien— andernfalls erhalten wir einen Fehler hinsichtlich des nicht konfigurierten JDK im Modul.
Obwohl diese Dateien normalerweise einbezogen werden, .gitignore, enthalten sie keine spezifischen Informationen, die auf die Umgebung eines bestimmten Entwicklers zugeschnitten sind — im Gegensatz zu beispielsweise der Datei workspace.xml, in der solche Informationen enthalten sind, und die daher nicht committiert werden sollte.
Es bietet sich an, das JDK zusammen mit der IDEA Community Edition in einen Container zu packen, der bereit ist, auf die analysierten Projekte angewendet zu werden. Wir wählen den passenden Basis-Container, und hier ist unser Dockerfile:
Dockerfile
VON 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 -v2Mit der Option idea.config.path haben wir IDEA veranlasst, nach ihrer globalen Konfiguration im Ordner /etc/idea, zu suchen, da das Heimatverzeichnis des Benutzers in CI-Umgebungen oft unbestimmt oder gar nicht vorhanden ist.
So sieht die Datei aus, die in den Container kopiert wird jdk.table.xml, in der die Pfade zu OpenJDK, das im Container installiert ist, definiert sind (eine ähnliche Datei kann aus Ihrem eigenen IDEA-Konfigurationsverzeichnis entnommen werden):
jdk.table.xml
Das Bild in der fertigen Form .
Bevor wir fortfahren, lassen Sie uns den IDEA-Analyzer im Container starten:
docker run --rm -v :/var/project inponomarev/intellij-idea-analyzerDie Analyse sollte erfolgreich abgeschlossen werden, und im Unterordner target/idea_inspections sollten zahlreiche .xml-Dateien mit den 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 in Form von .xml-Dateien zu erhalten, ist die halbe Miete; jetzt muss er lesbar gemacht werden. Außerdem sollten die Ergebnisse in Quality Gates verwendet werden – in der Logik, ob die angenommene Änderung die Qualitätskriterien erfüllt oder nicht.
Dabei hilft uns , dessen Veröffentlichung im Januar 2019 erfolgte. Mit seiner Einführung wurden viele einzelne Plugins für die Arbeit mit Ergebnissen der statischen Analyse in Jenkins (CheckStyle, FindBugs, PMD usw.) als veraltet (obsolete) gekennzeichnet.
Das Plugin besteht aus zwei Teilen:
- vielen Sammlern von Analyzer-Nachrichten ( umfasst alle bekannten Analysewerkzeuge von AcuCobol bis ZPT Lint.
- einen einheitlichen Berichtsanzeiger für alle.
Zu den Analysen, die Warnings NG durchführen kann, gehören unter anderem die Warnungen des Java-Compilers und Warnungen aus den Maven-Ausführungsprotokollen: Obwohl sie ständig sichtbar sind, werden sie selten gezielt analysiert. Auch Berichte aus IntelliJ IDEA gehören zu den unterstützten Formaten.
Da das Plugin neu ist, interagiert es von Anfang an gut mit Jenkins Pipeline. Der Build-Schritt wird folgendermaßen aussehen (wir sagen einfach dem Plugin, welches Berichtformat wir erkennen und welche Dateien gescannt 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:
Es ist praktisch, dass diese Oberfläche für alle erkannten Analyzer universell ist. Sie enthält ein interaktives Diagramm zur Verteilung der Funde nach Kategorien sowie ein Diagramm, das die Dynamik der Anzahl der Funde zeigt. Im Grid am unteren Ende der Seite können Sie eine schnelle Suche durchführen. Das Einzige, was für die Inspektionen in IDEA nicht richtig funktioniert hat, ist die Möglichkeit, den Code direkt in Jenkins zu durchsuchen (obwohl dieses Plugin dies für andere Berichte, wie Checkstyle, gut macht). Es scheint ein Fehler des Report-Analyzers in IDEA zu sein, den es zu beheben gilt.
Zu den Funktionen 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 „Ratschenmechanismus“ basierend auf dem Referenz-Build. Einige Dokumentationen zur Programmierung von Quality Gates sind verfügbar, — jedoch ist sie nicht vollständig, und man muss in die Quellcodes schauen. Auf der anderen Seite kann man für eine vollständige Kontrolle über die Vorgänge den „Ratschenmechanismus“ auch selbst implementieren (siehe meinen zu diesem Thema).
Fazit
Bevor ich mit der Erstellung dieses Materials begann, wollte ich nachsehen, ob bereits jemand auf Habr über dieses Thema geschrieben hat. Ich habe nur gefunden, mit , wo er sagt:
Soweit ich weiß, gibt es keine Integration mit Jenkins oder einem Maven-Plugin […] Im Grunde könnte jeder Enthusiast IDEA Community Edition und Jenkins verbinden, viele würden davon profitieren.
Was ist passiert: Nach zwei Jahren haben wir das Warnings NG Plugin und endlich ist diese Freundschaft Realität geworden!
Quelle: habr.com
