Изпълнение на IntelliJ IDEA инспекции на Jenkins

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

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

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

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

Инспекциите се стартират с помощта на скрипт bin/inspect.sh от инсталационната директория на IDEA. Необходимите параметри са:

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

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

• пътят до Java SDK ще бъде конфигуриран в IDE, в противен случай анализът няма да работи. Тези настройки се съдържат в конфигурационния файл 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:

Докер файл

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

<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>

Готовото изображение наличен в Docker Hub.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

Е, две години по-късно имаме Warnings NG Plugin и най-накрая това приятелство се осъществи!

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