IntelliJ IDEA verfügt heute über den fortschrittlichsten statischen Java-Code-Analysator, der in seinen Fähigkeiten solche „Veteranen“ wie weit hinter sich lässt и . Seine zahlreichen „Inspektionen“ überprüfen den Code auf verschiedene Aspekte, vom Codierungsstil bis hin zu typischen Fehlern.
Solange die Analyseergebnisse jedoch nur in der lokalen Schnittstelle der IDE des Entwicklers angezeigt werden, sind sie für den Entwicklungsprozess von geringem Nutzen. Statische Analyse Als erster Schritt der Build-Pipeline sollten deren Ergebnisse Qualitäts-Gates definieren, und der Build sollte fehlschlagen, wenn die Qualität-Gates nicht bestanden werden. Es ist bekannt, dass TeamCity CI in IDEA integriert ist. Aber auch wenn Sie TeamCity nicht verwenden, können Sie problemlos versuchen, IDEA-Inspektionen auf einem anderen CI-Server auszuführen. Ich schlage vor, dass Sie sehen, wie dies mit dem Plugin IDEA Community Edition, Jenkins und Warnings NG erreicht werden kann.
Schritt 1. Führen Sie die Analyse im Container aus und erhalten Sie einen Bericht
Auf den ersten Blick mag die Idee, eine IDE (Desktop-Anwendung!) in einem CI-System auszuführen, das keine grafische Oberfläche hat, zweifelhaft und sehr problematisch erscheinen. Glücklicherweise haben die IDEA-Entwickler die Möglichkeit zur Ausführung bereitgestellt и über die Befehlszeile. Darüber hinaus ist zum Ausführen von IDEA in diesem Modus kein Grafiksubsystem erforderlich und diese Aufgaben können auf Servern mit einer Text-Shell ausgeführt werden.
Inspektionen werden mithilfe eines Skripts gestartet bin/inspect.sh aus dem IDEA-Installationsverzeichnis. Die erforderlichen Parameter sind:
- vollständiger Pfad zum Projekt (relative Pfade werden nicht unterstützt),
- Pfad zur .xml-Datei mit Inspektionseinstellungen (normalerweise im Projekt unter .idea/inspectionProfiles/Project_Default.xml),
- Vollständiger Pfad zum Ordner, in dem .xml-Dateien mit Berichten zu den Analyseergebnissen gespeichert werden.
Darüber hinaus wird damit gerechnet
- Der Pfad zum Java SDK wird in der IDE konfiguriert, andernfalls funktioniert die Analyse nicht. Diese Einstellungen sind in der Konfigurationsdatei enthalten
jdk.table.xmlim globalen IDEA-Konfigurationsordner. Die globale IDEA-Konfiguration selbst befindet sich standardmäßig im Home-Verzeichnis des Benutzers, aber an diesem Ort im Ordneridea.properties. - Das analysierte Projekt muss ein gültiges IDEA-Projekt sein, für das Sie einige Dateien, die normalerweise ignoriert werden, der Versionskontrolle übergeben müssen, nämlich:
.idea/inspectionProfiles/Project_Default.xml— Analysatoreinstellungen, sie werden natürlich bei der Durchführung von Inspektionen im Container verwendet,.idea/modules.xml- andernfalls erhalten wir die Fehlermeldung „Dieses Projekt enthält keine Module“,.idea/misc.xml- andernfalls erhalten wir die Fehlermeldung „Das JDK ist für dieses Projekt nicht richtig konfiguriert“,*.iml-файлы– andernfalls erhalten wir eine Fehlermeldung über ein nicht konfiguriertes JDK im Modul.
Obwohl diese Dateien normalerweise in enthalten sind .gitignoreSie enthalten keine spezifischen Informationen zur Umgebung eines bestimmten Entwicklers – anders als beispielsweise eine Datei workspace.xml, wenn solche Informationen enthalten sind und daher keine Notwendigkeit besteht, sie festzuschreiben.
Die offensichtliche Lösung besteht darin, das JDK zusammen mit der IDEA Community Edition in einen Container zu packen, sodass es auf die analysierten Projekte „ausgespielt“ werden kann. Wählen wir einen geeigneten Basiscontainer aus. So sieht unsere Docker-Datei aus:
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 -v2Nutzung der Option idea.config.path Wir haben IDEA gezwungen, im Ordner nach seiner globalen Konfiguration zu suchen /etc/idea, da der Home-Ordner des Benutzers bei der Arbeit in CI eine unsichere Sache ist und oft völlig fehlt.
So sieht die in den Container kopierte Datei aus: jdk.table.xml, das die Pfade zu OpenJDK enthält, das im Container installiert ist (eine ähnliche Datei aus Ihrem eigenen Verzeichnis mit IDEA-Einstellungen kann als Grundlage genommen werden):
jdk.table.xml
<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>Das fertige Bild .
Bevor wir fortfahren, überprüfen wir, ob der IDEA-Analysator im Container ausgeführt wird:
docker run --rm -v <путь/к/вашему/проекту>:/var/project inponomarev/intellij-idea-analyzerDie Analyse sollte erfolgreich ausgeführt werden und zahlreiche XML-Dateien mit Analyseberichten sollten im Unterordner target/idea_inspections erscheinen.
Nun besteht kein Zweifel mehr daran, dass der IDEA-Analysator in jeder CI-Umgebung eigenständig ausgeführt werden kann, und wir gehen zum zweiten Schritt über.
Schritt 2. Zeigen Sie den Bericht an und analysieren Sie ihn
Den Bericht in Form von .xml-Dateien zu erhalten, ist die halbe Miete; jetzt müssen Sie ihn für Menschen lesbar machen. Und auch seine Ergebnisse sollten in Quality Gates verwendet werden – der Logik zur Bestimmung, ob die akzeptierte Änderung gemäß Qualitätskriterien erfolgreich ist oder nicht.
Das wird uns helfen , das im Januar 2019 veröffentlicht wurde. Mit der Einführung werden viele einzelne Plugins für die Arbeit mit statischen Analyseergebnissen in Jenkins (CheckStyle, FindBugs, PMD usw.) als veraltet markiert.
Das Plugin besteht aus zwei Teilen:
- zahlreiche Analysator-Nachrichtensammler ( umfasst alle der Wissenschaft bekannten Analysegeräte von AcuCobol bis ZPT Lint),
- ein einziger Berichtsviewer für alle.
Die Liste der Dinge, die Warnings NG analysieren kann, umfasst Warnungen vom Java-Compiler und Warnungen von Maven-Ausführungsprotokollen: Obwohl sie ständig sichtbar sind, werden sie selten speziell analysiert. IntelliJ IDEA-Berichte sind ebenfalls in der Liste der erkannten Formate enthalten.
Da das Plugin neu ist, interagiert es zunächst gut mit der Jenkins Pipeline. Der Build-Schritt mit seiner Beteiligung sieht folgendermaßen aus (wir teilen dem Plugin einfach mit, welches Berichtsformat wir erkennen und welche Dateien gescannt werden sollen):
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')]
)
}Die Berichtsoberfläche sieht folgendermaßen aus:
Praktischerweise ist diese Schnittstelle universell für alle gängigen Analysegeräte. Es enthält ein interaktives Diagramm der Verteilung der Funde nach Kategorien und ein Diagramm der Dynamik der Veränderungen der Anzahl der Funde. Sie können im Raster unten auf der Seite eine Schnellsuche durchführen. Das Einzige, was bei IDEA-Inspektionen nicht richtig funktionierte, war die Möglichkeit, Code direkt in Jenkins zu durchsuchen (obwohl dieses Plugin dies für andere Berichte, zum Beispiel Checkstyle, wunderbar kann). Offenbar handelt es sich hierbei um einen Fehler im IDEA-Berichtsparser, der behoben werden muss.
Zu den Funktionen von Warnings NG gehört die Möglichkeit, Erkenntnisse aus verschiedenen Quellen in einem Bericht zusammenzufassen und Quality Gates zu programmieren, einschließlich einer „Ratsche“ für die Referenzbaugruppe. Einige Dokumentationen zur Quality Gates-Programmierung sind verfügbar - Allerdings ist es nicht vollständig und Sie müssen sich den Quellcode ansehen. Um andererseits die vollständige Kontrolle über das Geschehen zu erhalten, kann die „Ratsche“ unabhängig implementiert werden (siehe meine zu diesem Thema).
Abschluss
Bevor ich mit der Vorbereitung dieses Materials begann, beschloss ich zu suchen: Hat jemand bereits auf Habré zu diesem Thema geschrieben? Ich habe nur gefunden с wo er sagt:
Soweit ich weiß, gibt es keine Integration mit Jenkins oder einem Maven-Plugin […] Im Prinzip könnte sich jeder Enthusiast mit der IDEA Community Edition und Jenkins anfreunden, viele würden davon nur profitieren.
Nun, zwei Jahre später haben wir das Warnings NG Plugin und endlich ist diese Freundschaft Wirklichkeit geworden!
Source: habr.com