🥇Exécution d'inspections IntelliJ IDEA sur Jenkins

IntelliJ IDEA dispose aujourd'hui de l'analyseur de code Java statique le plus avancé, qui, dans ses capacités, laisse loin derrière lui des « vétérans » tels que Style de contrôle и Bugs ponctuels. Ses nombreuses « inspections » vérifient le code sous divers aspects, du style de codage aux bugs typiques.

Cependant, tant que les résultats de l'analyse ne sont affichés que dans l'interface locale de l'EDI du développeur, ils sont de peu d'utilité au processus de développement. Analyse statique doit être rempli En tant que première étape du pipeline de build, ses résultats doivent définir des critères de qualité, et la build doit échouer si les critères de qualité ne sont pas franchis. On sait que TeamCity CI est intégré à IDEA. Mais même si vous n'utilisez pas TeamCity, vous pouvez facilement essayer d'exécuter des inspections IDEA sur n'importe quel autre serveur CI. Je vous suggère de voir comment cela peut être fait en utilisant le plugin IDEA Community Edition, Jenkins et Warnings NG.

Étape 1. Exécutez l'analyse dans le conteneur et obtenez un rapport

Au début, l'idée d'exécuter un IDE (application de bureau !) dans un système CI qui n'a pas d'interface graphique peut sembler douteuse et très gênante. Heureusement, les développeurs IDEA ont fourni la possibilité d'exécuter formatage du code и inspections à partir de la ligne de commande. De plus, pour exécuter IDEA dans ce mode, aucun sous-système graphique n'est requis et ces tâches peuvent être effectuées sur des serveurs dotés d'un shell texte.

Les inspections sont lancées à l'aide d'un script bin/inspect.sh à partir du répertoire d'installation d'IDEA. Les paramètres requis sont :

chemin complet vers le projet (les chemins relatifs ne sont pas pris en charge),
chemin d'accès au fichier .xml avec les paramètres d'inspection (généralement situé à l'intérieur du projet dans .idea/inspectionProfiles/Project_Default.xml),
chemin complet vers le dossier dans lequel seront stockés les fichiers .xml contenant les rapports sur les résultats de l'analyse.

De plus, il est prévu que

le chemin d'accès au SDK Java sera configuré dans l'EDI, sinon l'analyse ne fonctionnera pas. Ces paramètres sont contenus dans le fichier de configuration jdk.table.xml dans le dossier de configuration globale IDEA. La configuration globale IDEA elle-même se trouve par défaut dans le répertoire personnel de l'utilisateur, mais cet emplacement peut être explicitement spécifié dans le fichier idea.properties.
Le projet analysé doit être un projet IDEA valide, pour lequel vous devrez valider certains fichiers habituellement ignorés au contrôle de version, à savoir :
- .idea/inspectionProfiles/Project_Default.xml — les paramètres de l'analyseur, ils seront évidemment utilisés lors des contrôles effectués dans le conteneur,
- .idea/modules.xml - sinon nous aurons l'erreur 'Ce projet ne contient aucun module',
- .idea/misc.xml - sinon nous aurons l'erreur 'Le JDK n'est pas configuré correctement pour ce projet',
- *.iml-файлы - sinon nous obtiendrons une erreur concernant un JDK non configuré dans le module.

Bien que ces fichiers soient généralement inclus dans .gitignore, ils ne contiennent aucune information spécifique à l'environnement d'un développeur particulier - contrairement par exemple à un fichier workspace.xml, où ces informations sont contenues, et il n'est donc pas nécessaire de les valider.

La solution évidente consiste à regrouper le JDK avec IDEA Community Edition dans un conteneur sous une forme prête à être « testée » sur les projets analysés. Choisissons un conteneur de base approprié, et voici ce que sera notre 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

Utilisation de l'option idea.config.path nous avons forcé IDEA à chercher sa configuration globale dans le dossier /etc/idea, car le dossier personnel de l’utilisateur lorsqu’il travaille dans CI est une chose incertaine et souvent complètement absente.

Voici à quoi ressemble le fichier copié dans le conteneur : jdk.table.xml, qui contient les chemins d'accès à OpenJDK installé dans le conteneur (un fichier similaire de votre propre répertoire avec les paramètres IDEA peut être pris comme base) :

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>

L'image finie disponible sur Docker Hub.

Avant de continuer, vérifions que l'analyseur IDEA s'exécute dans le conteneur :

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

L'analyse doit s'exécuter correctement et de nombreux fichiers .xml contenant des rapports d'analyse doivent apparaître dans le sous-dossier target/idea_inspections.

Il ne fait désormais plus aucun doute que l'analyseur IDEA peut être exécuté de manière autonome dans n'importe quel environnement CI, et nous passons à la deuxième étape.

Étape 2. Afficher et analyser le rapport

Obtenir le rapport sous forme de fichiers .xml représente la moitié de la bataille ; vous devez maintenant le rendre lisible par l'homme. Et ses résultats doivent également être utilisés dans les contrôles de qualité - la logique permettant de déterminer si le changement accepté réussit ou échoue selon des critères de qualité.

Cela nous aidera Plugin Jenkins Avertissements NG, sorti en janvier 2019. Avec son avènement, de nombreux plugins individuels permettant de travailler avec les résultats d'analyse statique dans Jenkins (CheckStyle, FindBugs, PMD, etc.) sont désormais marqués comme obsolètes.

Le plugin se compose de deux parties :

de nombreux collecteurs de messages d'analyseur (La liste complète comprend tous les analyseurs connus de la science, de l'AcuCobol au ZPT Lint),
un seul visualiseur de rapports pour tous.

La liste des éléments que Warnings NG peut analyser comprend les avertissements du compilateur Java et les avertissements des journaux d'exécution de Maven : bien qu'ils soient constamment visibles, ils sont rarement analysés spécifiquement. Les rapports IntelliJ IDEA sont également inclus dans la liste des formats reconnus.

Étant donné que le plugin est nouveau, il interagit initialement bien avec Jenkins Pipeline. L'étape de construction avec sa participation ressemblera à ceci (nous indiquons simplement au plugin quel format de rapport nous reconnaissons et quels fichiers doivent être analysés) :

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')]
    )
}

L'interface du rapport ressemble à ceci :

Idéalement, cette interface est universelle pour tous les analyseurs reconnus. Il contient un schéma interactif de la répartition des trouvailles par catégorie et un graphique de la dynamique d'évolution du nombre de trouvailles. Vous pouvez effectuer une recherche rapide dans la grille en bas de page. La seule chose qui ne fonctionnait pas correctement pour les inspections IDEA était la possibilité de parcourir le code directement dans Jenkins (bien que pour d'autres rapports, par exemple Checkstyle, ce plugin puisse le faire à merveille). Il semble qu'il s'agisse d'un bug dans l'analyseur de rapport IDEA qui doit être corrigé.

Parmi les fonctionnalités de Warnings NG figure la possibilité de regrouper les résultats de différentes sources dans un seul rapport et de programmer des Quality Gates, y compris un « cliquet » pour l'assemblage de référence. Une documentation de programmation Quality Gates est disponible ici - cependant, il n'est pas complet et il faut regarder le code source. En revanche, pour un contrôle total sur ce qui se passe, le « cliquet » peut être mis en œuvre indépendamment (voir mon редыдущий ост sur ce thème).

Conclusion

Avant de commencer à préparer ce matériel, j'ai décidé de chercher : quelqu'un a-t-il déjà écrit sur ce sujet sur Habré ? j'ai seulement trouvé entretien 2017 с lanyoù il dit :

Autant que je sache, il n'y a pas d'intégration avec Jenkins ou un plugin maven […] En principe, tout passionné pourrait se lier d'amitié avec IDEA Community Edition et Jenkins, beaucoup n'en bénéficieraient que.

Eh bien, deux ans plus tard, nous avons Warnings NG Plugin, et enfin cette amitié s'est concrétisée !

Source: habr.com

Exécutez les inspections IntelliJ IDEA sur Jenkins

Étape 1. Exécutez l'analyse dans le conteneur et obtenez un rapport

Étape 2. Afficher et analyser le rapport

Conclusion

Ajouter un commentaire Annuler la réponse