🥇Запускаме инспекции IntelliJ IDEA на Jenkins

Интегрирането на IntelliJ IDEA днес осигурява най-напредналия статичен анализатор на Java код, който значително изпреварва дългогодишни имена като Checkstyle и Spotbugs. Неговите многобройни „инспекции“ проверяват кода по различни аспекти, от стил на кодиране до типични бъгове.

Въпреки това, докато резултатите от анализа се показват само в локалния интерфейс на IDE на разработчика, те не предлагат много полза за процеса на разработка. Статичният анализ трябва да се извършва като първа стъпка в процеса на изграждане, резултатите от него трябва да определят quality gates и изграждането трябва да се проваля, ако quality gates не са преминати. Известно е, че TeamCity CI е интегриран с IDEA. Но дори и да не използвате TeamCity, можете да опитате да стартирате инспекциите на IDEA на всяка друга CI-сървър. Предлагам да видим как може да стане това, използвайки IDEA Community Edition, Jenkins и Warnings NG plugin.

Стъпка 1. Стартиране на анализа в контейнера и получаване на отчет

Първоначално идеята да стартирате IDE (десктопно приложение!) в CI-система без графичен интерфейс може да изглежда съмнителна и доста трудоемка. За щастие, разработчиците на IDEA предоставиха възможност за стартиране на форматиране на кода и инспекции от командния ред. За стартиране на IDEA в този режим не се изисква графична подсистема и тези задачи могат да се извършват на сървъри с текстова обвивка.

Стартирането на инспекции се извършва чрез скрипт bin/inspect.sh от инсталационната директория на IDEA. Изискват се следните параметри:

пълен път до проекта (относителни не се поддържат),
път до .xml файла с настройки за инспекции (обикновено се намира вътре в проекта в .idea/inspectionProfiles/Project_Default.xml),
пълен път до папката, в която ще бъдат съхранявани .xml файловете с отчетите от анализа.

Освен това, се очаква, че

в IDE ще бъде настроен пътя до Java SDK, в противен случай анализът няма да работи. Тези настройки се съдържат в конфигурационния файл jdk.table.xml в папката за глобалната конфигурация на IDEA. Сама по себе си глобалната конфигурация на IDEA по подразбиране е в домашната директория на потребителя, но това местоположение може да бъде зададено явно в файла idea.properties.
анализираният проект трябва да бъде валиден проект на IDEA, за което е необходимо да се добавят някои файлове, които обикновено се игнорират, в системата за контрол на версиите, а именно:
- .idea/inspectionProfiles/Project_Default.xml — настройки на анализатора ще бъдат използвани при стартиране на инспекции в контейнера,
- .idea/modules.xml — иначе ще получим грешка ‘Този проект не съдържа модули’,
- .idea/misc.xml — иначе ще получим грешка ‘JDK не е конфигуриран правилно за този проект’,
- *.iml файлове — иначе ще получим грешка за неконфигуриран JDK в модула.

Обикновено, тези файлове включват .gitignore, но не съдържат никаква специфична информация за средата на конкретния разработчик — за разлика от, например, файла workspace.xml, където такава информация, всъщност, се съдържа, и затова не трябва да се комитва.

На лице е необходимостта да опаковаме JDK заедно с IDEA Community Edition в контейнер в готов вид за ‘натравяне’ на анализираните проекти. Нека изберем подходящ базов контейнер, и ето какъв ще бъде нашият 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

С опцията idea.config.path накарахме IDEA да търси глобалната си конфигурация в папката /etc/idea, тъй като домашната папка на потребителя в условия на работа в CI — е неясна и често въобще не съществува.

Така изглежда файлът, който се копира в контейнера, jdk.table.xml, в който са зададени пътищата към OpenJDK, инсталирана вътре в контейнера (може да се използва аналогичен файл от вашата собствена директория с настройки на IDEA):

jdk.table.xml

Готово достъпен в Docker Hub.

Преди да продължим, нека проверим стартирането на анализатора IDEA в контейнера:

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

Анализът трябва да завърши успешно, а в подпапката target/idea_inspections трябва да се появят множество .xml файла с отчетите на анализатора.

Сега вече няма съмнение, че анализаторът IDEA може да бъде стартиран офлайн в всяка CI среда, и преминаваме към втората стъпка.

Стъпка 2. Показваме и анализираме отчета

Получаването на отчет във формат .xml е само половината от задачата; сега той трябва да бъде направен четим за хората. Освен това, резултатите му трябва да бъдат използвани в quality gates - логиката за определяне дали приеманата промяна отговаря на критериите за качество.

В това ще ни помогне Плагин за предупреждения Jenkins NG, чието издание беше направено през януари 2019 година. С появата му много отделни плъгини за работа с резултатите от статичния анализ в Jenkins (CheckStyle, FindBugs, PMD и др.) сега са маркирани като остарели.

Плагинът се състои от две части:

многобройни сборници на съобщения от анализаторите (пълен списък включва всички известни анализатори от AcuCobol до ZPT Lint),
и един общ преглед на отчетите за всички тях.

Списъкът с това, което Warnings NG може да анализира, включва и предупреждения от Java компилатора, както и предупреждения от логовете на Maven: въпреки че те са постоянно пред очите ни, рядко се анализират целенасочено. Отчетите на IntelliJ IDEA също влизат в списъка на разпознаваемите формати.

Тъй като плъгинът е нов, той е проектиран да работи добре с Jenkins Pipeline. Стъпката за изграждане с неговото участие би изглеждала по следния начин (просто казваме на плъгина какъв формат на отчет разпознаваме и кои файлове трябва да бъдат сканирани):

stage ('Статичен анализ'){ 
    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')] 
    ) 
}

Интерфейсът на отчета изглежда така:

Удобно е, че този интерфейс е универсален за всички разпознаваеми анализатори. Съдържа интерактивна диаграма за разпределение на находките по категории и график за динамика на промените в броя находки. В долната част на страницата можете да извършите бързо търсене. Единственото, което не работи коректно за инспекциите на IDEA, е възможността да се разглежда кодът директно в Jenkins (въпреки че за други отчети, например Checkstyle, този плъгин прави това добре). Изглежда, че това е бъг на парсера на отчетите на IDEA, който трябва да бъде поправен.

Сред възможностите на Warnings NG е възможността да се агрегира в един отчет находките от различни източници и да се програмират Quality Gates, включително - «храповик» по референтната сборка. Някои документация по програмирането на Quality Gates е налична. тук. — впрочем, тя не е завършена и трябва да се гледа в източниците. От друга страна, за пълен контрол върху случващото се, 'храповикът' може да бъде реализиран и самостоятелно (вижте моя предишен пост по тази тема).

Заключение

Преди да започна с подготовката на този материал, реших да потърся: дали някой вече е писал на тази тема в Хабра? Намерих само интервю от 2017 година с lany, където той казва:

Доколкото ми е известно, няма интеграция с Jenkins или maven плъгин […] По принцип, всеки ентусиаст би могъл да свърже IDEA Community Edition и Jenkins, много хора биха спечелили от това.

Какво да кажем: след две години имаме Warnings NG Plugin, и най-накрая тази дружба се осъществи!

Източник: habr.com

Стартираме инспекции на IntelliJ IDEA в Jenkins

Стъпка 1. Стартиране на анализа в контейнера и получаване на отчет

Стъпка 2. Показваме и анализираме отчета

Заключение