Az IntelliJ IDEA ma a legfejlettebb Java kód statikus elemzővel rendelkezik, amely képességeivel messze maga mögött hagyja az olyan „öreg motorosokat”, mint és . Számos „ellenőrzése” különböző szempontok szerint vizsgálja a kódot, a kódolási stílustól kezdve a tipikus hibákig.
Mindazonáltal, mivel az elemzési eredmények jelenleg csak a fejlesztő IDE helyi felületén jelennek meg, alig van hasznuk a fejlesztési folyamat során. A statikus elemzést , az eredményeknek minőségi kapukat kell meghatározniuk, és a fordításnak el kell döcögnie, ha a minőségi kapuk nem teljesülnek. Ismert, hogy a TeamCity CI integrálva van az IDE-vel. De még ha nem is használ TeamCity-t, a vizsgálatokat bármilyen más CI szerveren futtathatja. Javaslom, nézzük meg, hogyan lehet ezt megtenni az IDEA Community Edition, a Jenkins és a Warnings NG plugin segítségével.
1. lépés: Elemzés indítása a tartályban és riport beszerzése
Első ránézésre furcsának és nagyon macerásnak tűnhet az IDE (asztali alkalmazás!) CI rendszeren belüli futtatása, amelynek nincs grafikus felülete. Szerencsére az IDEA fejlesztői lehetőséget biztosítottak a és parancssorból való futtatására. Ráadásul az IDEA ilyen üzemmódban történő futtatásához nem szükséges grafikus alrendszer, és ezeket a feladatokat szöveges kezelőfelületű szervereken is el lehet végezni.
Az ellenőrzések indítása a bin/inspect.sh scripts segítségével történik az IDEA telepítési könyvtárából. Paraméterként szükséges:
- a projekt teljes elérési útja (a relatív nem támogatott),
- az ellenőrzések beállításait tartalmazó .xml fájl elérési útja (általában a projektben található a .idea/inspectionProfiles/Project_Default.xml alatt),
- a teljes elérési útja annak a mappának, ahová az elemzés eredményéről szóló .xml fájlokat kell elhelyezni.
Ezenkívül várakozunk, hogy
- az IDE-ben a Java SDK elérési útja be legyen állítva, különben az elemzés nem fog működni. Ezek a beállítások a
jdk.table.xmlkonfigurációs fájlban találhatók az IDEA globális konfigurációs mappájában. Az IDEA globális konfigurációja alapértelmezés szerint a felhasználó otthoni könyvtárában található, de ez a hely meghatározható a fájlbanAz elemezett projektnek érvényes IDEA projektnek kell lennie, ezért a verziókezelés során el kell kötelezni néhány fájlt, amelyeket általában figyelmen kívül hagynak, nevezetesen:. - .idea/inspectionProfiles/Project_Default.xml
.idea/inspectionProfiles/Project_Default.xml— az elemző beállításai, ezek egyértelműen fel lesznek használva a konténerben végzett ellenőrzések indításakor,.idea/modules.xml— különben ‘Ez a projekt nem tartalmaz modulokat’ hibaüzenetet kapunk,.idea/misc.xml— különben ‘A JDK nincs megfelelően beállítva ehhez a projekthez’ hibaüzenetet kapunk,*.iml fájlok— különben hibaüzenetet kapunk, amely a modulban nem beállított JDK-ra vonatkozik.
Bár ezek a fájlok általában tartalmazzák .gitignore, nem tartalmaznak semmilyen a konkrét fejlesztői környezetre vonatkozó specifikus információt — ellentétben például a workspace.xml, ahol ilyen információk szerepelnek, és ezért azt nem kellene elkötelezni.
Természetesen adódik a lehetőség, hogy a JDK-t a IDEA Community Edition-nel együtt csomagoljuk a konténerbe, amely készen áll a vizsgálandó projektek „felnyomására”. Válasszunk ki egy megfelelő alap konténert, és így fog kinézni a 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 -v2A idea.config.path opció segítségével arra kényszerítettük az IDEA-t, hogy a globális konfigurációt a /etc/idea, mivel a felhasználó otthoni könyvtára a CI környezetében bizonytalan dolog, és gyakran teljesen hiányzik.
Így néz ki a konténerbe másolt fájl, jdk.table.xml, amely tartalmazza az OpenJDK-hoz vezető útvonalakat, amelyek a konténeren belül vannak telepítve (az alapot egy hasonló fájl képezheti a saját IDEA beállítási könyvtáradból):
jdk.table.xml
Kész kép .
Mielőtt továbblépnénk, ellenőrizzük, hogy az IDEA elemző fut-e a konténerben:
docker run --rm -v :/var/project inponomarev/intellij-idea-analyzerAz elemzésnek sikeresen le kell futnia, és a target/idea_inspections almappában számos .xml fájl készül az elemző jelentéseivel.
Most már nincs kétség afelől, hogy az IDEA elemző offline üzemmódban is futtatható bármilyen CI környezetben, és áttérünk a második lépésre.
2. lépés. A jelentés megjelenítése és elemzése
A jelentés megszerzése .xml fájl formátumban fél munka, most emberi olvasásra is alkalmassá kell tenni. Továbbá az eredményeit fel kell használni a quality gates logikájában, amely meghatározza, hogy a bevezetett változtatás megfelel-e a minőségi kritériumoknak vagy sem.
Ebben segít nekünk , amelynek kiadása 2019 januárjában történt. Megjelenésével sok különálló Jenkins plugin a statikus analízis eredményeivel kapcsolatban (CheckStyle, FindBugs, PMD stb.) most elavultnak (obsolete) minősül.
A plugin két részből áll:
- a különböző analízis gyűjtők közül ( melyek tartalmazzák az összes tudományos elemzőt az AcuCoboltól a ZPT Lintig),
- és az ezekhez tartozó egységes jelentésmegjelenítőről.
A Warnings NG analizáló lista tartalmazza a Java fordító figyelmeztetéseit és a Maven végrehajtási naplókból származó figyelmeztetéseket: noha ezek folyamatosan szem előtt vannak, ritkán elemzik őket célzottan. Az IntelliJ IDEA jelentések szintén szerepelnek a támogatható formátumok között.
Mivel a plugin új, jól működik a Jenkins Pipeline-lal. A benne részt vevő build szakasz a következőképpen fog kinézni (egyszerűen csak megmondjuk a pluginnek, hogy mely jelentésformátumokat ismerjük fel, és mely fájlokat kell áttekinteni):
stage ('Statikus elemzés'){
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')]
)
}A jelentés felülete így néz ki:
Kellemes, hogy ez az interfész univerzális minden támogatott elemző számára. Tartalmaz egy interaktív diagramot a kategóriákba sorolt megállapítások eloszlásáról és egy grafikont a megállapítások számának változásáról. Az oldal alján levő gridben gyors keresést lehet végezni. Az egyetlen dolog, ami nem működött megfelelően az IDEA ellenőrzéseknél, az a lehetőség, hogy közvetlenül a kódböngészés a Jenkinsben (bár más jelentéseknél, például a Checkstyle-nál, ez a plugin szépen meg tudja csinálni). Úgy tűnik, ez egy hiba az IDEA jelentések parserében, amit javítani kell.
A Warnings NG lehetőségei közé tartozik, hogy egy jelentésben aggregálhatók a különböző forrásokból származó megállapítások, valamint a Quality Gates programozása, beleértve a "kapcsoló órát" a referencia build alapján. Néhány dokumentáció a Quality Gates programozásáról elérhető. — azonban ez nem teljes, és néha a forrásokhoz kell fordulni. Másrészt a folyamat teljes ellenőrzéséhez a „ratchet” megoldást saját magunk is megvalósíthatjuk (lásd az én erről a témáról).
Zárás
Mielőtt elkezdtem volna ezt az anyagot összegyűjteni, kerestem, hogy írt-e már valaki erről a témáról a Habr-nál? Csak a , ahol azt mondja:
Tudomásom szerint nincs integráció Jenkins-szel vagy maven pluginnel […] Gyakorlatilag bármelyik lelkes amatőr összeboronálhatná az IDEA Community Edition-t és a Jenkins-t, sokan csak nyernének ebből.
Mi történt: két év elteltével megvan a Warnings NG Plugin, és végre megtörtént ez a barátság!
Forrás: habr.com
