🥇 Kjører IntelliJ IDEA-inspeksjoner på Jenkins

IntelliJ IDEA har i dag den mest avanserte statiske Java-kodeanalysatoren, som i sine evner etterlater seg langt bak slike "veteraner" som Sjekkstil и Spotbugs. Dens mange "inspeksjoner" sjekker koden i forskjellige aspekter, fra kodestil til typiske feil.

Men så lenge analyseresultatene bare vises i det lokale grensesnittet til utviklerens IDE, er de til liten nytte for utviklingsprosessen. Statisk analyse må oppfylles Som det første trinnet i byggepipelinen, bør resultatene definere kvalitetsporter, og bygget skal mislykkes hvis kvalitetsportene ikke passeres. Det er kjent at TeamCity CI er integrert med IDEA. Men selv om du ikke bruker TeamCity, kan du enkelt prøve å kjøre IDEA-inspeksjoner i en hvilken som helst annen CI-server. Jeg foreslår at du ser hvordan dette kan gjøres ved å bruke IDEA Community Edition, Jenkins og Warnings NG-plugin.

Trinn 1. Kjør analysen i beholderen og få en rapport

Til å begynne med kan ideen om å kjøre en IDE (desktop-applikasjon!) inne i et CI-system som ikke har et grafisk grensesnitt virke tvilsom og veldig plagsom. Heldigvis har IDEA-utviklere gitt muligheten til å kjøre kodeformatering и inspeksjoner fra kommandolinjen. Dessuten, for å kjøre IDEA i denne modusen, er det ikke nødvendig med et grafikkundersystem, og disse oppgavene kan utføres på servere med et tekstskall.

Inspeksjoner startes ved hjelp av et skript bin/inspect.sh fra IDEA-installasjonskatalogen. De nødvendige parametrene er:

full vei til prosjektet (slektninger støttes ikke),
bane til .xml-filen med inspeksjonsinnstillinger (vanligvis plassert inne i prosjektet i .idea/inspectionProfiles/Project_Default.xml),
full bane til mappen der .xml-filer med rapporter om analyseresultatene vil bli lagret.

I tillegg er det forventet at

banen til Java SDK vil bli konfigurert i IDE, ellers vil ikke analysen fungere. Disse innstillingene finnes i konfigurasjonsfilen jdk.table.xml i IDEA globale konfigurasjonsmappen. Den globale IDEA-konfigurasjonen er som standard plassert i brukerens hjemmekatalog, men denne plasseringen kan spesifiseres eksplisitt i fil idea.properties.
Det analyserte prosjektet må være et gyldig IDEA-prosjekt, som du må forplikte deg til noen filer som vanligvis ignoreres til versjonskontroll, nemlig:
- .idea/inspectionProfiles/Project_Default.xml - analysatorinnstillinger, de vil åpenbart bli brukt når du kjører inspeksjoner i containeren,
- .idea/modules.xml - ellers får vi feilen 'Dette prosjektet inneholder ingen moduler',
- .idea/misc.xml - ellers får vi feilen 'JDK er ikke riktig konfigurert for dette prosjektet',
- *.iml-файлы – ellers får vi en feilmelding om en ukonfigurert JDK i modulen.

Selv om disse filene vanligvis er inkludert i .gitignore, inneholder de ingen informasjon som er spesifikk for miljøet til en bestemt utvikler - i motsetning til for eksempel en fil workspace.xml, der slik informasjon er inneholdt, og det derfor ikke er behov for å begå den.

Den åpenbare løsningen er å pakke JDK sammen med IDEA Community Edition i en beholder i en form som er klar til å bli "pitted" på de analyserte prosjektene. La oss velge en passende basebeholder, og dette er hva vår Dockerfile vil være:

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

Bruker alternativet idea.config.path vi tvang IDEA til å se etter den globale konfigurasjonen i mappen /etc/idea, fordi brukerens hjemmemappe når du jobber i CI er en usikker ting og ofte helt fraværende.

Slik ser filen som er kopiert til beholderen ut: jdk.table.xml, som inneholder banene til OpenJDK installert inne i beholderen (en lignende fil fra din egen katalog med IDEA-innstillinger kan tas som grunnlag):

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>

Det ferdige bildet tilgjengelig på Docker Hub.

Før vi går videre, la oss sjekke at IDEA-analysatoren kjører i beholderen:

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

Analysen skal kjøre vellykket, og mange XML-filer med analysatorrapporter skal vises i undermappen target/idea_inspections.

Nå er det ikke lenger noen tvil om at IDEA-analysatoren kan kjøres frittstående i ethvert CI-miljø, og vi går videre til andre trinn.

Trinn 2. Vis og analyser rapporten

Å få rapporten i form av .xml-filer er halve kampen, nå må du gjøre den lesbar for mennesker. Og resultatene bør også brukes i kvalitetsporter - logikken for å avgjøre om den aksepterte endringen passerer eller mislykkes i henhold til kvalitetskriterier.

Dette vil hjelpe oss Jenkins Warnings NG Plugin, som ble utgitt i januar 2019. Med introduksjonen er mange individuelle plugins for arbeid med statiske analyseresultater i Jenkins (CheckStyle, FindBugs, PMD, etc.) nå merket som foreldet.

Programtillegget består av to deler:

mange analysatormeldingssamlere (hele listen inkluderer alle analysatorer kjent for vitenskapen fra AcuCobol til ZPT Lint),
én enkelt rapportviser for dem alle.

Listen over ting som Warnings NG kan analysere inkluderer advarsler fra Java-kompilatoren og advarsler fra Maven-utførelseslogger: selv om de er konstant synlige, blir de sjelden spesifikt analysert. IntelliJ IDEA-rapporter er også inkludert i listen over anerkjente formater.

Siden plugin-en er ny, samhandler den i utgangspunktet godt med Jenkins Pipeline. Byggetrinnet med dets deltakelse vil se slik ut (vi forteller ganske enkelt pluginen hvilket rapportformat vi gjenkjenner og hvilke filer som skal skannes):

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

Rapportgrensesnittet ser slik ut:

Beleilig er dette grensesnittet universelt for alle anerkjente analysatorer. Den inneholder et interaktivt diagram over fordelingen av funn etter kategori og en graf over dynamikken til endringer i antall funn. Du kan utføre et raskt søk i rutenettet nederst på siden. Det eneste som ikke fungerte riktig for IDEA-inspeksjoner var muligheten til å bla gjennom kode direkte i Jenkins (selv om for andre rapporter, for eksempel Checkstyle, kan denne pluginen gjøre dette vakkert). Det ser ut til at dette er en feil i IDEA-rapportparseren som må fikses.

Blant funksjonene til Warnings NG er muligheten til å samle funn fra forskjellige kilder i én rapport og programmere Quality Gates, inkludert en "skralle" for referanseenheten. Noe Quality Gates-programmeringsdokumentasjon er tilgjengelig her - den er imidlertid ikke komplett, og du må se på kildekoden. På den annen side, for full kontroll over hva som skjer, kan "skrallen" implementeres uavhengig (se min forrige innlegg om dette temaet).

Konklusjon

Før jeg begynte å forberede dette materialet, bestemte jeg meg for å søke: har noen allerede skrevet om dette emnet på Habré? jeg bare fant intervju 2017 с Lanyhvor han sier:

Så vidt jeg vet er det ingen integrasjon med Jenkins eller en maven-plugin […] I prinsippet kan enhver entusiast bli venner med IDEA Community Edition og Jenkins, mange ville bare ha nytte av dette.

Vel, to år senere har vi Warnings NG Plugin, og endelig har dette vennskapet kommet i oppfyllelse!

Kilde: www.habr.com

Kjører IntelliJ IDEA-inspeksjoner på Jenkins

Trinn 1. Kjør analysen i beholderen og få en rapport

Trinn 2. Vis og analyser rapporten

Konklusjon

Legg til en kommentar Avbryt svar