Vi kör IntelliJ IDEA-inspektioner på Jenkins

IntelliJ IDEA har idag den mest avancerade statiska kodanalysatorn för Java, vilket lämnar långt bakom sig sådana "veteraner" som Checkstyle och Spotbugs. Dess många "inspektioner" kontrollerar koden ur olika aspekter, från kodstil till typiska buggar.

Men hittills visas analysresultaten bara i utvecklarens lokala IDE-gränssnitt, vilket gör dem ganska ineffektiva för utvecklingsprocessen. Statisk analys bör utföras som det första steget i byggprocessen; dess resultat bör definiera quality gates, och bygget bör misslyckas om quality gates inte uppfylls. Det är känt att TeamCity CI är integrerat med IDEA. Men även om du inte använder TeamCity kan du helt enkelt försöka köra inspektioner i IDEA på vilken annan CI-server som helst. Låt oss titta på hur detta kan göras med hjälp av IDEA Community Edition, Jenkins och Warnings NG-plugin.

Steg 1. Starta analysen i containern och få en rapport

Till en början kan det verka tveksamt och mycket besvärligt att starta IDE (ett skrivbordsprogram!) inuti en CI-system utan grafiskt gränssnitt. Lyckligtvis har utvecklarna av IDEA gett möjlighet att köra kodformatering och inspektioner från kommandoraden. För att starta IDEA i detta läge krävs ingen grafisk subsystem, och dessa uppgifter kan utföras på servrar med textgränssnitt.

Inspektionerna startas med hjälp av skriptet bin/inspect.sh från installationsmappen för IDEA. Som parametrar behövs:

• fullständig sökväg till projektet (relativa sökvägar stöds inte),
• sökväg till .xml-filen med inspektionsinställningarna (som vanligtvis finns i projektmappen i .idea/inspectionProfiles/Project_Default.xml),
• fullständig sökväg till mappen där .xml-filer med analysresultatens rapporter ska lagras.

Dessutom förväntas

• i IDE:s inställningar finnas en referens till Java SDK, annars kommer analysen inte att fungera. Dessa inställningar finns i konfigurationsfilen jdk.table.xml i IDEA:s globala konfigurationsmapp. Själva den globala konfigurationen för IDEA ligger som standard i användarens hemkatalog, men denna plats kan anges uttryckligen i filen idea.properties.
• det analyserade projektet måste vara ett giltigt IDEA-projekt, vilket innebär att vissa filer som normalt ignoreras måste kommittas till kontrollsystemet, nämligen:
  • .idea/inspectionProfiles/Project_Default.xml — konfiguration av analysatorn, de kommer uppenbarligen att användas när inspektioner körs i containern,
  • .idea/modules.xml — annars får vi felet 'Detta projekt innehåller inga moduler',
  • .idea/misc.xml — annars får vi felet 'JDK:n är inte korrekt konfigurerad för detta projekt',
  • *.iml-filer — annars får vi ett fel om att JDK inte är inställt i modulen.

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

Det föreslår sig självt att packa JDK tillsammans med IDEA Community Edition i en container i en form som är redo för att används på analyserade projekt. Vi väljer en lämplig grundcontainer, och här är vad vi får i 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

Genom att använda alternativet idea.config.path tvingade vi IDEA att söka efter sin globala konfiguration i mappen /etc/idea, eftersom användarens hemkatalog i CI-arbetsmiljöer är osäker och ofta helt saknas.

Så här ser filen ut som kopieras till containern, jdk.table.xml, där sökvägarna till OpenJDK, installerad inuti containern, är angivna (en liknande fil kan tas som utgångspunkt från din egen konfigurationskatalog för IDEA):

jdk.table.xml

Bild i färdig form tillgänglig på Docker Hub.

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

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

Analysen ska köras utan problem och i undermappen target/idea_inspections ska det finnas många .xml-filer med analysrapporter.

Nu finns det inga tvivel om att IDE-analyzern kan köras offline i vilket CI-miljö som helst, och vi går vidare till steg två.

Steg 2. Visar och analyserar rapporten

Att få rapporten i form av .xml-filer är en del av arbetet, nu måste den göras läsbar för människor. Dessutom måste resultaten användas i quality gates – logiken för att avgöra om den accepterade ändringen uppfyller kvalitetskriterierna.

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

Pluginet består av två delar:

• ett stort antal meddelandeaggregatorer från analysatorer (fullständig lista inklusive alla kända analysatorer från AcuCobol till ZPT Lint),
• en gemensam rapportvisare för alla dessa.

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

Eftersom pluginet är nytt fungerar det från början bra med Jenkins Pipeline. Steget för byggprocessen ser ut som följande (vi berättar bara för pluginet vilket rapportformat vi känner igen och vilka filer som ska skannas):

stage ('Statisk analys'){ 
    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änssnitt 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 efter kategorier och en graf som visar hur antalet fynd förändras över tid. I rutan längst ner på sidan kan snabb sökning utföras. Det enda som inte fungerade korrekt för IDEA-inspektionerna var möjligheten att bläddra i koden direkt i Jenkins (även om denna plugin kan göra det snyggt för andra rapporter, till exempel Checkstyle). Det verkar vara en bugg i parsern för IDEA-rapporter som behöver fixas.

Bland möjligheterna i Warnings NG finns möjlighet att aggregatera fynd från olika källor i en rapport och att programmera Quality Gates, inklusive – en "ratchet" baserad på referensbyggnaden. Viss dokumentation om programmering av Quality Gates finns tillgänglig. här — men den är inte fullständig, och man får titta i källorna. Å andra sidan, för full kontroll över vad som händer kan "växeln" också implementeras själv (se min tidigare post i detta ämne).

Slutsats

Innan jag började förbereda detta material, bestämde jag mig för att se om någon redan skrivit om detta 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 kunde vilken entusiast som helst koppla ihop IDEA Community Edition och Jenkins, många skulle bara vinna på det.

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

Källa: habr.com