Интегрирането на IntelliJ IDEA днес осигурява най-напредналия статичен анализатор на Java код, който значително изпреварва дългогодишни имена като и . Неговите многобройни „инспекции“ проверяват кода по различни аспекти, от стил на кодиране до типични бъгове.
Въпреки това, докато резултатите от анализа се показват само в локалния интерфейс на 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
Готово .
Преди да продължим, нека проверим стартирането на анализатора IDEA в контейнера:
docker run --rm -v :/var/project inponomarev/intellij-idea-analyzerАнализът трябва да завърши успешно, а в подпапката target/idea_inspections трябва да се появят множество .xml файла с отчетите на анализатора.
Сега вече няма съмнение, че анализаторът IDEA може да бъде стартиран офлайн в всяка CI среда, и преминаваме към втората стъпка.
Стъпка 2. Показваме и анализираме отчета
Получаването на отчет във формат .xml е само половината от задачата; сега той трябва да бъде направен четим за хората. Освен това, резултатите му трябва да бъдат използвани в quality gates - логиката за определяне дали приеманата промяна отговаря на критериите за качество.
В това ще ни помогне , чието издание беше направено през януари 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 е налична. — впрочем, тя не е завършена и трябва да се гледа в източниците. От друга страна, за пълен контрол върху случващото се, 'храповикът' може да бъде реализиран и самостоятелно (вижте моя по тази тема).
Заключение
Преди да започна с подготовката на този материал, реших да потърся: дали някой вече е писал на тази тема в Хабра? Намерих само с , където той казва:
Доколкото ми е известно, няма интеграция с Jenkins или maven плъгин […] По принцип, всеки ентусиаст би могъл да свърже IDEA Community Edition и Jenkins, много хора биха спечелили от това.
Какво да кажем: след две години имаме Warnings NG Plugin, и най-накрая тази дружба се осъществи!
Източник: habr.com
