🥇Vi lancerer inspektioner i IntelliJ IDEA på Jenkins

IntelliJ IDEA har i dag den mest avancerede statiske Java kodeanalyse, som klart har overgået "veteraner" såsom Checkstyle og Spotbugs. Dens mange "inspektioner" tjekker koden fra forskellige vinkler, lige fra kodestil til typiske fejl.

Men indtil videre vises analysens resultater kun i udviklerens lokale IDE-grænseflade, hvilket gør dem mindre nyttige i udviklingsprocessen. Statisk analyse skal udføres som det første skridt i byggeprocessen, og dens resultater bør definere quality gates, hvor bygningen skal fejle, hvis quality gates ikke er bestået. Det er kendt, at TeamCity CI er integreret med IDEA. Men selv hvis du ikke bruger TeamCity, kan du nemt forsøge at køre inspektioner fra IDEA på enhver anden CI-server. Lad os se på, hvordan det kan gøres ved hjælp af IDEA Community Edition, Jenkins og Warnings NG plugin.

Trin 1. Kør analysen i en container og få rapporten

I starten kan ideen om at køre IDE (desktopapplikation!) inde i en CI-system uden grafisk interface virke tvivlsom og meget besværlig. Heldigvis har udviklerne af IDEA givet mulighed for at køre kodeformatering og inspektioner fra kommandolinjen. Og for at køre IDEA i denne tilstand kræves der ikke en grafisk subsystem, og disse opgaver kan udføres på servere med tekstbaseret shell.

Inspektionerne startes ved hjælp af scriptet bin/inspect.sh fra installationsmappen af IDEA. Parametre, der kræves, inkluderer:

den fulde sti til projektet (relative stier understøttes ikke),
stien til .xml-filen med inspektionsindstillinger (som normalt findes inde i projektet i .idea/inspectionProfiles/Project_Default.xml),
den fulde sti til den mappe, hvor .xml-filerne med rapporter om analysemulighederne skal placeres.

Derudover forventes det, at

IDE'en har stien til Java SDK konfigureret, ellers vil analysen ikke fungere. Disse indstillinger findes i konfigurationsfilen jdk.table.xml i IDEA's globale konfigurationsmappe. Den globale konfiguration for IDEA ligger som standard i brugerens hjemmemappe, men denne placering kan angives eksplicit i filen idea.properties.
det analyserede projekt skal være et gyldigt IDEA-projekt, hvilket betyder, at nogle filer, som normalt ignoreres, skal committes til versionskontrol, nemlig:
- .idea/inspectionProfiles/Project_Default.xml — indstillinger for analysatoren, de vil bestemt blive brugt ved kørsel af inspektioner i containeren,
- .idea/modules.xml — ellers får vi fejlen ‘Dette projekt indeholder ingen moduler’,
- .idea/misc.xml — ellers får vi fejlen ‘JDK'en er ikke korrekt konfigureret til dette projekt’,
- *.iml-filer — ellers får vi en fejl om ikke-konfigureret JDK i modulet.

Selvom disse filer normalt inkluderer .gitignore, indeholder de ingen specifik information for den enkelte udvikler — i modsætning til for eksempel filen workspace.xml, hvor sådan information netop er indeholdt, og derfor skal vi ikke committe den.

Det giver mening at pakke JDK sammen med IDEA Community Edition ind i en container i en form, der er klar til at blive 'sat på' de analyserede projekter. Lad os vælge en passende basiskontainer, og her er hvordan vores Dockerfile vil se ud:

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

Ved hjælp af indstillingen idea.config.path fik vi IDEA til at søge sin globale konfiguration i mappen /etc/idea, da brugernes hjemmemappe i CI-miljøet er en usikker størrelse og ofte slet ikke eksisterer.

Sådan ser den fil ud, der kopieres ind i containeren jdk.table.xml, hvor stierne til OpenJDK, som er installeret inde i containeren, er angivet (en lignende fil fra din egen IDEA-indstillingsmappe kan bruges som grundlag):

jdk.table.xml

Billedet i sin færdige form er tilgængeligt på Docker Hub.

Før vi går videre, lad os kontrollere, at IDEA-analyzatoren starter i containeren:

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

Analysen skal gennemføres med succes, og der skal oprettes mange .xml-filer med rapporter fra analysatoren i undermappen target/idea_inspections.

Nu er der ikke længere nogen tvivl om, at IDEA-analyzatoren kan køres offline i et hvilket som helst CI-miljø, og vi går videre til trin to.

Trin 2. Vis og analyser rapporten

At få rapporten i form af .xml-filer er halvdelen af arbejdet, nu skal den gøres læsbar for mennesker. Desuden skal resultaterne bruges i quality gates - logikken for, om en modtaget ændring opfylder kvalitetskriterierne eller ej.

Dette vil hjælpe os med Jenkins Warnings NG Plugin, hvis lancering fandt sted i januar 2019. Med dens ankomst er mange separate plugins til arbejde med resultater fra statisk analyse i Jenkins (CheckStyle, FindBugs, PMD mv.) nu markeret som forældede (obsolete).

Plugin’et består af to dele:

mange samlere af analyserapporter (over forbudte porte). som inkluderer alle kendte analyser fra AcuCobol til ZPT Lint),
én fælles rapportvisning for dem alle.

Blandt det, Warnings NG kan analysere, er også Java-kompilatorens advarsler og advarsler fra Maven-udførselens logs: selvom de konstant er i fokus, bliver de sjældent analyseret målrettet. Rapporterne fra IntelliJ IDEA er også blandt de genkendte formater.

Da pluggin’et er nyt, interagerer det fra starten godt med Jenkins Pipeline. Byggeprocessen med det involverede vil se således ud (vi siger blot til plugin’et, hvilken rapportformat vi genkender og hvilke filer der skal scannes):

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

Rapportens grænseflade ser således ud:

Det er praktisk, at denne grænseflade er universel for alle genkendte analyser. Den indeholder et interaktivt diagram over fordelingen af fund efter kategori og en graf over ændringerne i antal fund over tid. I bunden af siden kan der foretages hurtige søgninger. Det eneste, der ikke fungerede korrekt for IDEA-inspektionerne, er muligheden for at browse koden direkte i Jenkins (selvom denne plugin klarer sig flot for andre rapporter som Checkstyle). Det synes at være en bug i parseren for IDEA-rapporter, som skal rettes.

Blandt Warnings NG’s funktioner er muligheden for at aggregere fund fra forskellige kilder i én rapport og programmere Quality Gates, herunder en „lås“ på den referente bygning. Nogen dokumentation til programmering af Quality Gates er tilgængelig. her — dog, den er ikke fuld, og man er nødt til at se på kildeteksten. På den anden side kan man implementere en "ratchet" selv for fuld kontrol over processen (se min tidligere indlæg til dette emne).

Konklusion

Før jeg begyndte at forberede dette materiale, besluttede jeg at søge efter, om nogen allerede havde skrevet om dette emne på Habr? Jeg fandt kun et interview fra 2017 med lany, hvor han siger:

Så vidt jeg ved, findes der ingen integration med Jenkins eller maven-plugin […] I princippet kunne enhver entusiast forbinde IDEA Community Edition og Jenkins, mange ville kun få fordel af det.

Så hvad: efter to år har vi Warnings NG Plugin, og endelig er dette venskab blevet en realitet!

Kilde: habr.com

Vi starter IntelliJ IDEA-inspektioner på Jenkins

Trin 1. Kør analysen i en container og få rapporten

Trin 2. Vis og analyser rapporten

Konklusion