Vi kör IntelliJ IDEA-inspektioner på Jenkins

IntelliJ IDEA har idag den mest avancerade statiska kodanalysatorn för Java, med färdigheter som överträffar sådana "veteraner" som Checkstyle och Spotbugs. Dess många "inspektioner" kontrollerar koden ur olika aspekter, från kodningsstil till vanliga buggar.

Men tills resultaten av analysen visas endast i IDE:ns lokala gränssnitt, är de av liten nytta för utvecklingsprocessen. Statisk analys måste utföras som det första steget i byggkedjan, dess resultat ska definiera quality gates, och bygget ska misslyckas om quality gates inte godkänns. Det är känt att TeamCity CI är integrerat med IDEA. Men även om du inte använder TeamCity, kan du enkelt köra inspektioner från IDEA på vilken annan CI-server som helst. Jag föreslår att vi tittar på hur detta kan göras med hjälp av IDEA Community Edition, Jenkins och Warnings NG-plugin.

Steg 1. Kör analysen i containern och få en rapport

Till en början kan tanken på att köra IDE (ett desktopprogram!) inom en CI-system utan grafiskt gränssnitt verka tveksam och mycket besvärlig. Lyckligtvis har utvecklarna av IDEA tillhandahållit möjligheten att köra kodformattering och inspektioner från kommandoraden. För att köra IDEA i detta läge krävs ingen grafisk underhållning, och dessa uppgifter kan utföras på servrar med textgränssnitt.

Inspektionerna körs med skriptet bin/inspect.sh från installationskatalogen för IDEA. Som parametrar krävs:

• den fullständiga sökvägen till projektet (relativa stigar stöds inte),
• sökvägen till .xml-filen med inspektionsinställningar (finns vanligtvis inuti projektet på .idea/inspectionProfiles/Project_Default.xml),
• den fullständiga sökvägen till mappen där .xml-filer med analysresultat kommer att sparas.

Dessutom förväntas det att

• i IDE är sökvägen till Java SDK inställd, annars kommer analysen inte att fungera. Dessa inställningar återfinns i konfigurationsfilen jdk.table.xml i IDEA:s globala konfigurationsmapp. Själva den globala konfigurationen av IDEA ligger som standard i användarens hemmakatalog, men denna plats kan anges explicit i filen idea.properties.
• det analyserade projektet måste vara ett giltigt IDEA-projekt, vilket kräver att vissa filer som vanligtvis ignoreras måste committas i versionskontrollen, nämligen:
  • .idea/inspectionProfiles/Project_Default.xml — inställningar för analysatorn, som uppenbarligen kommer att användas vid körning av inspektioner i containern,
  • .idea/modules.xml — annars får vi felmeddelandet ‘Detta projekt innehåller inga moduler’,
  • .idea/misc.xml — annars får vi felmeddelandet ‘JDK: n är inte korrekt konfigurerad för detta projekt’,
  • *.iml-filer — annars får vi ett felmeddelande om en oconfigurerad JDK i modulen.

Även om dessa filer vanligtvis inkluderar .gitignore, innehåller de ingen information som är specifik för den enskilde utvecklaren — till skillnad från, till exempel, filen workspace.xml, där sådan information finns, och därför ska vi inte checka in den.

Det föreslår sig nästan att packa in JDK tillsammans med IDEA Community Edition i containern i en form redo för att "utvecklas" på analyserade projekt. Låt oss välja en lämplig bascontainer och här är vårt resultat 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

Med hjälp av alternativet idea.config.path har vi tvingat IDEA att söka sin globala konfiguration i mappen /etc/idea, eftersom användarens hemmamapp i CI-miljöer är en osäker sak och ofta helt saknas.

Så här ser filen ut som kopieras till containern jdk.table.xml, där sökvägarna till OpenJDK, som är installerad inuti containern, är angivna (en liknande fil från din egen IDEA-konfigurationsmapp kan användas som grund):

jdk.table.xml

Bild i färdig form finns på Docker Hub.

Innan vi går vidare, låt oss kontrollera att IDEA-analysatorn körs i containern:

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

Analysen ska genomföras framgångsrikt, och i undermappen target/idea_inspections kommer många .xml-filer med analyserapporter att dyka upp.

Nu finns det inga tvivel om att IDEA-analysatorn kan köras i fristående läge i vilken CI-miljö som helst, och vi går vidare till steg två.

Steg 2. Visa och analysera rapporten

Att få en rapport i form av .xml-filer är halva jobbet, nu måste den göras läsbar för människor. Dessutom ska resultaten användas i quality gates — logiken för att avgöra om den accepterade ändringen uppfyller kvalitetskriterier.

Det här hjälper oss med Jenkins Warnings NG Plugin, vars release gjordes i januari 2019. Med dess ankomst är många enskilda plugins för att arbeta med resultaten från statisk analys i Jenkins (CheckStyle, FindBugs, PMD osv.) nu märkta som föråldrade (obsolete).

Pluginet består av två delar:

• ett stort antal analysators meddelandesamlare (fullständig lista som inkluderar alla kända analysatorer från AcuCobol till ZPT Lint),
• en gemensam rapportvisare för dem alla.

Bland de saker som Warnings NG kan analysera finns också Java-kompilatorns varningar och varningar från Maven-körloggar: även om de alltid är synliga, analyseras de sällan direkt. Rapporter från IntelliJ IDEA ingår också i listan över erkända format.

Eftersom pluginet är nytt interagerar det från början väl med Jenkins Pipeline. Byggsteget med dess deltagande kommer att se ut som följer (vi säger helt enkelt till pluginet 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 praktiskt att detta gränssnitt är universellt för alla erkända analysatorer. Det innehåller ett interaktivt diagram som visar fördelningen av fynd per kategori och en graf över förändringar i antalet fynd. I gridden längst ner på sidan kan man utföra snabb sökning. Det enda som inte riktigt fungerade för inspektionerna i IDEA var möjligheten att bläddra i koden direkt i Jenkins (även om detta plugin kan göra det fint för andra rapporter, som Checkstyle). Det verkar vara en bugg i parsern för IDEA-rapporter som måste åtgärdas.

Bland funktionerna i Warnings NG finns möjligheten att aggregera fynd från olika källor i en rapport och programmera Quality Gates, inklusive en "ratchet" baserat på referensbygget. Viss dokumentation om programmering av Quality Gates finns tillgänglig. här — förresten, den är inte komplett, och man måste titta i källorna. Å andra sidan, för att få full kontroll över vad som händer kan man också implementera en "backande" själv (se min tidigare inlägg i det här ämnet).

Slutsats

Innan jag började förbereda detta material beslutade jag mig för att kolla: har någon redan skrivit om detta ämne på Habré? Jag hittade endast en intervju från 2017 med lany, där han säger:

Såvitt jag vet finns det ingen integration med Jenkins eller maven-plugin […] I princip skulle vilken entusiast som helst kunna koppla ihop IDEA Community Edition och Jenkins, vilket många skulle dra nytta av.

Så vad händer: efter två år har vi Warnings NG Plugin, och äntligen har denna vänskap blivit verklighet!

Källa: habr.com