Водење на IntelliJ IDEA инспекции на Џенкинс

IntelliJ IDEA денес го има најнапредниот статичен Java анализатор на код, кој во своите можности остава далеку зад себе такви „ветерани“ како што се Стил на проверка и Spotbugs. Нејзините бројни „инспекции“ го проверуваат кодот во различни аспекти, од стил на кодирање до типични грешки.

Меѓутоа, сè додека резултатите од анализата се прикажуваат само во локалниот интерфејс на 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:

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 е половина од битката сега треба да го направите читлив за луѓе. И, исто така, неговите резултати треба да се користат во портите за квалитет - логиката за утврдување дали прифатената промена поминува или не успева според критериумите за квалитет.

Ова ќе ни помогне Џенкинс Предупредувања НГ приклучок, кој беше објавен во јануари 2019 година. Со неговото појавување, многу поединечни приклучоци за работа со резултати од статичка анализа во Џенкинс (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 беше можноста за прелистување на кодот директно во Џенкинс (иако за други извештаи, на пример Checkstyle, овој приклучок може да го направи тоа прекрасно). Изгледа ова е грешка во анализаторот за извештаи IDEA што треба да се поправи.

Меѓу карактеристиките на Warnings NG е способноста да се збират наоди од различни извори во еден извештај и да се програмира Quality Gates, вклучително и „растелка“ за референтното собрание. Достапна е програмска документација за Quality Gates тука - сепак, не е комплетен, и мора да го погледнете изворниот код. Од друга страна, за целосна контрола врз она што се случува, „стаклата“ може да се имплементира независно (види мое претходен пост за оваа тема).

Заклучок

Пред да почнам да го подготвувам овој материјал, решив да пребарувам: дали некој веќе пишувал на оваа тема на Хабре? Најдов само интервју 2017 година с ланикаде што вели:

Колку што знам, нема интеграција со Џенкинс или мавен приклучок […] Во принцип, секој ентузијаст може да се дружи со IDEA Community Edition и Jenkins, многумина би имале само корист од ова.

Па, две години подоцна го имаме Warnings NG Plugin, и конечно ова пријателство се оствари!

Извор: www.habr.com