Kör IntelliJ IDEA-inspektioner på Jenkins

IntelliJ IDEA har för närvarande den mest avancerade statiska Java-kodanalysatorn, som i sin kapacitet har lämnat sådana "veteraner" som Checkstyle и Spotbugs. Dess många "inspektioner" kontrollerar koden för olika aspekter, från kodningsstil till vanliga buggar.

Men så länge som analysresultaten endast visas i det lokala gränssnittet för utvecklarens IDE, är de till liten nytta för utvecklingsprocessen. Statisk analys måste utföras Som det första steget i byggpipelinen bör dess resultat avgöra kvalitetsgrindar, och bygget bör misslyckas om kvalitetsgrindarna inte passeras. Det är känt att TeamCity CI är integrerat med IDEA. Men även om du inte använder TeamCity kan du fortfarande prova att köra IDEA-inspektioner på vilken annan CI-server som helst. Jag föreslår att du tittar på hur detta kan göras med IDEA Community Edition, Jenkins och Warnings NG plugin.

Steg 1. Kör analysen i behållaren och hämta rapporten

Till en början kan idén att köra en IDE (en skrivbordsapplikation!) inuti ett CI-system som inte har ett grafiskt gränssnitt verka tvivelaktig och mycket besvärlig. Lyckligtvis har IDEA-utvecklarna gett möjligheten att köra kodformatering и inspektioner från kommandoraden. För att köra IDEA i detta läge krävs dessutom inget grafiskt delsystem och dessa uppgifter kan utföras på servrar med ett textskal.

Inspektioner startas med hjälp av ett skript bin/inspect.sh från IDEA-installationskatalogen. Följande parametrar krävs:

• fullständig sökväg till projektet (relativa sökvägar stöds inte),
• sökväg till .xml-filen med inspektionsinställningar (vanligtvis placerad i projektet i .idea/inspectionProfiles/Project_Default.xml),
• den fullständiga sökvägen till mappen där .xml-filerna med analysresultatrapporterna kommer att lagras.

Dessutom förväntas det

• Sökvägen till Java SDK kommer att konfigureras i IDE, annars fungerar inte analysen. Dessa inställningar finns i konfigurationsfilen. jdk.table.xml i IDEA globala konfigurationsmappen. Själva den globala IDEA-konfigurationen finns som standard i användarens hemkatalog, men den här platsen kan uttryckligen anges i fil idea.properties.
• det analyserade projektet måste vara ett giltigt IDEA-projekt, för vilket du måste överlåta vissa filer till versionskontroll som vanligtvis ignoreras, nämligen:
  • .idea/inspectionProfiles/Project_Default.xml — analysatorinställningar, de kommer uppenbarligen att användas vid inspektioner i behållaren,
  • .idea/modules.xml - annars får vi felet 'Detta projekt innehåller inga moduler',
  • .idea/misc.xml - annars får vi felet "JDK är inte korrekt konfigurerad för detta projekt",
  • *.iml-файлы — annars får vi ett felmeddelande om att JDK inte är konfigurerad i modulen.

Även om dessa filer vanligtvis ingår i .gitignore, innehåller de ingen information som är specifik för miljön för en viss utvecklare - till skillnad från till exempel en fil workspace.xml, där sådan information finns och det därför inte finns något behov av att begå den.

Den uppenbara lösningen är att packa JDK tillsammans med IDEA Community Edition i en container i en form redo att "ställas in på" de projekt som analyseras. Låt oss välja en lämplig basbehållare, och så här kommer vår Dockerfile att se ut:

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

Använder alternativet idea.config.path vi fick IDEA att leta efter dess globala konfiguration i mappen /etc/idea, eftersom användarens hemmapp i CI-förhållanden är en odefinierad sak och ofta helt frånvarande.

Så här ser en fil som kopierats till en behållare ut jdk.table.xml, som anger sökvägarna till OpenJDK installerat i behållaren (en liknande fil från din egen katalog med IDEA-inställningar kan användas som bas):

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>

Den färdiga bilden tillgänglig på Docker Hub.

Innan vi går vidare, låt oss kontrollera lanseringen av IDEA-analysatorn i behållaren:

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

Analysen ska slutföras framgångsrikt, och många .xml-filer med analysrapporter bör visas i undermappen target/idea_inspections.

Nu råder det ingen tvekan om att IDEA-analysatorn kan köras i fristående läge i vilken CI-miljö som helst, och vi går vidare till det andra steget.

Steg 2. Visa och analysera rapporten

Att få en rapport i form av .xml-filer är halva striden, nu måste den göras läsbar för människor. Och dess resultat bör också användas i kvalitetsgrindar - logiken för att avgöra om en accepterad förändring godkänns eller misslyckas enligt kvalitetskriterier.

Detta kommer att hjälpa oss Jenkins Warnings NG Plugin, som släpptes i januari 2019. Med sin introduktion är många individuella plugins för att arbeta med statiska analysresultat i Jenkins (CheckStyle, FindBugs, PMD, etc.) nu markerade som föråldrade.

Insticksprogrammet består av två delar:

• många meddelandeinsamlare analysatorer (hela listan inkluderar alla kända vetenskapliga analysatorer från AcuCobol till ZPT Lint),
• en enda rapportvisare för dem alla.

Listan över saker som Warnings NG kan analysera inkluderar Java-kompilatorvarningar och varningar från Mavens exekveringsloggar: även om de är ständigt synliga, analyseras de sällan med avsikt. IntelliJ IDEA-rapporter ingår också i listan över erkända format.

Eftersom plugin-programmet är nytt interagerar det initialt bra med Jenkins Pipeline. Byggsteget som involverar det kommer att se ut så här (vi berättar bara för plugin vilket rapportformat vi känner igen och vilka filer som ska skannas):

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

Rapportgränssnittet ser ut så här:

Det är bekvämt att detta gränssnitt är universellt för alla erkända analysatorer. Den innehåller ett interaktivt diagram över fyndfördelningen per kategori och en graf över dynamiken i förändringar i antalet fynd. Du kan göra en snabb sökning i rutnätet längst ner på sidan. Det enda som inte fungerade korrekt för IDEA-inspektioner var möjligheten att bläddra i kod direkt i Jenkins (även om för andra rapporter, som Checkstyle, kan detta plugin göra det bra). Det ser ut som att detta är en bugg i IDEA:s rapportparser som måste fixas.

Varningar NG-funktioner inkluderar möjligheten att samla resultat från olika källor i en rapport och programmera Quality Gates, inklusive en "spärr" för referensenheten. Viss dokumentation om programmering av Quality Gates finns tillgänglig här - den är dock inte komplett, och du måste titta på källkoden. Å andra sidan, för fullständig kontroll över vad som händer, kan "spärren" implementeras oberoende (se min föregående inlägg om detta ämne).

Slutsats

Innan jag började förbereda det här materialet bestämde jag mig för att söka: har någon redan skrivit om detta ämne på Habr? Jag hittade bara intervju 2017 с lany, där han säger:

Så vitt jag vet finns det ingen integration med Jenkins eller maven plugin […] I princip kan vilken entusiast som helst få vänner mellan IDEA Community Edition och Jenkins, många skulle bara dra nytta av detta.

Tja, två år senare har vi Warnings NG Plugin, och äntligen har denna vänskap blivit sann!

Källa: will.com