IntelliJ IDEA dispune astăzi de cel mai avansat analizor static de cod Java, lăsând în urmă "veteranii" precum și . Numeroasele sale „inspecții” verifică codul din diverse perspective, de la stilul de codare până la erorile caracteristice.
Cu toate acestea, până acum, rezultatele analizei sunt afișate doar în interfața locală a IDE-ului dezvoltatorului, având astfel puțină utilitate pentru procesul de dezvoltare. Analiza statică ca prim pas al procesului de construire, iar rezultatele sale ar trebui să definească quality gates, iar construcția ar trebui să eșueze dacă quality gates nu sunt respectate. Se știe că TeamCity CI este integrat cu IDEA. Dar chiar dacă nu folosești TeamCity, poți încerca să rulezi inspecțiile IDEA pe orice alt server CI. Propun să vedem cum se poate face acest lucru folosind IDEA Community Edition, Jenkins și plugin-ul Warnings NG.
Pasul 1. Lansăm analiza în container și obținem raportul
La început, ideea de a rula IDE-ul (aplicație desktop!) în cadrul unei sisteme CI care nu are interfață grafică poate părea discutabilă și foarte complicată. Din fericire, dezvoltatorii IDEA au oferit posibilitatea de a rula și din linia de comandă. Și pentru a lansa IDEA în acest mod, nu este necesară o subsistem grafic, iar aceste sarcini pot fi efectuate pe servere cu interfață text.
Lansarea inspecțiilor se realizează prin intermediul scriptului bin/inspect.sh din directorul de instalare IDEA. Ca parametri sunt necesari:
- calea completă către proiect (nu sunt acceptate căile relative),
- calea către fișierul .xml cu setările inspecțiilor (de obicei situat în interiorul proiectului în .idea/inspectionProfiles/Project_Default.xml),
- calea completă către folderul în care vor fi stocate fișierele .xml cu rapoartele rezultatelor analizei.
În plus, se așteaptă ca
- în IDE să fie configurată calea către Java SDK, altfel analiza nu va funcționa. Aceste setări se află în fișierul de configurare
jdk.table.xmlîn folderul de configurație globală al IDEA. Configurația globală a IDEA se află, în mod implicit, în directorul de acasă al utilizatorului, dar această locație în fișierulidea.properties. - proiectul analizat trebuie să fie un proiect IDEA valid, pentru care va fi necesar să angajăm în controlul versiunilor anumite fișiere care, de obicei, sunt ignorate, și anume:
.idea/inspectionProfiles/Project_Default.xml— setările analizerului, acestea vor fi folosite în mod evident la rularea inspecțiilor în container,.idea/modules.xml— altfel vom obține eroarea ‘Acest proiect nu conține module’,.idea/misc.xml— altfel vom obține eroarea ‘JDK nu este configurat corect pentru acest proiect’,*.iml-fișiere— altfel vom obține eroarea legată de JDK neconfigurat în modul.
Deși de obicei aceste fișiere includ în .gitignore, ele nu conțin nicio informație specifică mediului pentru un anumit dezvoltator — spre deosebire de, de exemplu, fișierul workspace.xml, unde informații precum acestea sunt conținute și prin urmare nu trebuie angajat.
Se sugerează destul de natural să împachetăm JDK împreună cu IDEA Community Edition în container într-o formă pregătită pentru a fi utilizată pe proiectele analizate. Vom alege un container de bază potrivit, iar iată cum va arăta Dockerfile-ul nostru:
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 -v2Prin opțiunea idea.config.path am făcut ca IDEA să caute configurația sa globală în folderul /etc/idea, deoarece folderul de acasă al utilizatorului în condițiile de lucru în CI este o noțiune incertă și adesea chiar inexistentă.
Așa arată fișierul copiat în container jdk.table.xml, în care sunt specificate căile către OpenJDK, instalat în interiorul containerului (se poate folosi un fișier similar din propriul director cu setările IDEA):
jdk.table.xml
Imagine în formă finală .
Înainte de a merge mai departe, să verificăm lansarea analizatorului IDEA în container:
docker run --rm -v :/var/project inponomarev/intellij-idea-analyzerAnaliza ar trebui să fie finalizată cu succes, iar în subfolderul target/idea_inspections ar trebui să apară numeroase fișiere .xml cu rapoartele analizatorului.
Acum nu mai există nicio îndoială că analizatorul IDEA poate fi lansat offline în orice mediu CI, iar acum trecem la pasul doi.
Pasul 2. Vizualizăm și analizăm raportul
Obținerea unui raport în format .xml este doar o parte din proces; acum trebuie să fie făcut ușor de citit pentru oameni. De asemenea, rezultatele sale trebuie utilizate în calitate de gates – logica de a determina dacă modificarea acceptată îndeplinește criteriile de calitate.
Acest lucru ne va ajuta , lansat în ianuarie 2019. Odată cu apariția sa, multe pluginuri individuale pentru gestionarea rezultatelor analizei statice în Jenkins (CheckStyle, FindBugs, PMD etc.) sunt acum marcate ca fiind depășite (obsolete).
Pluginul este format din două părți:
- numeroase colectoare de mesaje pentru analizatori ( include toți analizatorii cunoscuți, de la AcuCobol la ZPT Lint),
- un vizualizator de rapoarte unic pentru toate acestea.
Lista a ceea ce poate analiza Warnings NG include, printre altele, avertismentele compilatorului Java și avertismentele din jurnalele de execuție Maven: deși acestea sunt mereu vizibile, ele sunt rareori analizate în mod specific. Rapoartele IntelliJ IDEA sunt, de asemenea, incluse în lista formatelor recunoscute.
Fiind un plugin nou, acesta interacționează bine cu Jenkins Pipeline. Pasul de construcție care implică acest plugin va arăta astfel (noi spunem pur și simplu pluginului ce format de raport recunoaștem și ce fișiere trebuie să fie scanate):
stage ('Analiză statică'){
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')]
)
}Interfața raportului arată astfel:
Este convenabil că această interfață este universală pentru toți analizatorii recunoșcuți. Aceasta conține un grafic interactiv care ilustrează distribuția descoperirilor pe categorii și un grafic al evoluției numărului de descoperiri. În gridul de la baza paginii se poate efectua o căutare rapidă. Singurul lucru care nu a funcționat corect pentru inspecțiile IDEA este posibilitatea de a naviga în cod direct în Jenkins (deși pentru alte rapoarte, cum ar fi Checkstyle, acest plugin managează acest lucru cu eleganță). Se pare că este un bug al parserului pentru rapoartele IDEA, care trebuie rezolvat.
Printre funcționalitățile Warnings NG se numără posibilitatea de a agrega într-un singur raport descoperirile din diferite surse și de a programa Quality Gates, inclusiv – o "frână" pe construcția de referință. Unele documentații pentru programarea Quality Gates sunt disponibile. — cu toate acestea, nu este completă, iar pentru a avea un control total asupra evenimentelor, "clichetul" poate fi implementat și manual (vezi postarea mea pe această temă).
Concluzie
Înainte de a începe să pregătesc acest material, am decis să caut: a scris cineva despre acest subiect pe Habra? Am găsit doar de , în care spune:
Din câte știu, nu există integrare cu Jenkins sau plugin pentru maven […] În principiu, orice entuziast ar putea conecta IDEA Community Edition și Jenkins, mulți ar beneficia de pe urma acestui lucru.
Ce să zic: după doi ani avem Plugin-ul Warnings NG și, în sfârșit, această colaborare s-a realizat!
Sursa: habr.com
