Kurante IntelliJ IDEA-inspektadojn sur Jenkins

IntelliJ IDEA hodiaŭ havas la plej altnivelan statikan Java-kodan analizilon, kiu laŭ siaj kapabloj forlasas tiajn "veteranojn" kiel Kontrolstilo и Spotcimoj. Ĝiaj multnombraj "inspektadoj" kontrolas la kodon en diversaj aspektoj, de kodstilo ĝis tipaj eraroj.

Tamen, kondiĉe ke la analizrezultoj estas nur montrataj en la loka interfaco de la IDE de la programisto, ili malmulte utilas al la evoluprocezo. Statika analizo devas esti plenumita Kiel la unua paŝo de la konstrua dukto, ĝiaj rezultoj devus difini kvalitajn pordegojn, kaj la konstruo devus malsukcesi se la kvalitpordegoj ne estas preterpasitaj. Oni scias, ke TeamCity CI estas integrita kun IDEA. Sed eĉ se vi ne uzas TeamCity, vi povas facile provi fari IDEA-inspektadojn en iu ajn alia CI-servilo. Mi sugestas, ke vi vidu kiel tio povas esti farita per IDEA Community Edition, Jenkins kaj Warnings NG kromaĵo.

Paŝo 1. Rulu la analizon en la ujo kaj ricevu raporton

Komence, la ideo funkcii IDE (skribotabla aplikaĵo!) ene de CI-sistemo, kiu ne havas grafikan interfacon, povas ŝajni dubinda kaj tre ĝena. Feliĉe, IDEA-programistoj disponigis la kapablon funkcii kodformatado и inspektoj de la komandlinio. Krome, por ruli IDEA en ĉi tiu reĝimo, grafika subsistemo ne estas bezonata kaj ĉi tiuj taskoj povas esti plenumitaj sur serviloj kun teksta ŝelo.

Inspektadoj estas lanĉitaj per skripto bin/inspect.sh el la instala dosierujo de IDEA. La bezonataj parametroj estas:

  • plena vojo al la projekto (relativaj ne estas subtenataj),
  • vojo al la .xml-dosiero kun inspektaj agordoj (kutime situanta ene de la projekto en .idea/inspectionProfiles/Project_Default.xml),
  • plena vojo al la dosierujo en kiu .xml dosieroj kun raportoj pri la analizrezultoj estos konservitaj.

Krome, oni atendas ke

  • la vojo al la Java SDK estos agordita en la IDE, alie la analizo ne funkcios. Ĉi tiuj agordoj estas enhavitaj en la agorda dosiero jdk.table.xml en la IDEA tutmonda agorda dosierujo. La tutmonda agordo de IDEA mem troviĝas en la hejma dosierujo de la uzanto defaŭlte, sed ĉi tiu loko povas esti eksplicite precizigita en dosiero idea.properties.
  • La analizita projekto devas esti valida IDEA-projekto, por kiu vi devos transigi kelkajn dosierojn, kiuj estas kutime ignoritaj al versio-kontrolo, nome:
    • .idea/inspectionProfiles/Project_Default.xml — agordoj de analizilo, ili evidente estos uzataj kiam oni faras inspektadojn en la ujo,
    • .idea/modules.xml - alie ni ricevos la eraron 'Ĉi tiu projekto enhavas neniujn modulojn',
    • .idea/misc.xml - alie ni ricevos la eraron 'La JDK ne estas agordita ĝuste por ĉi tiu projekto',
    • *.iml-файлы — alie ni ricevos eraron pri neagordita JDK en la modulo.

Kvankam ĉi tiuj dosieroj estas kutime inkluzivitaj en .gitignore, ili ne enhavas ajnajn informojn specifajn por la medio de aparta programisto - male al, ekzemple, dosiero workspace.xml, kie tiaj informoj estas enhavitaj, kaj tial ne necesas fari ĝin.

La evidenta solvo estas paki la JDK kune kun IDEA Community Edition en ujon en formo preta por esti "fosita" sur la analizitaj projektoj. Ni elektu taŭgan bazan ujon, kaj jen kio estos nia 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

Uzante la opcion idea.config.path ni devigis IDEA serĉi ĝian tutmondan agordon en la dosierujo /etc/idea, ĉar la hejma dosierujo de la uzanto kiam laboras en CI estas necerta afero kaj ofte tute forestanta.

Jen kiel aspektas la dosiero kopiita al la ujo: jdk.table.xml, kiu enhavas la vojojn al OpenJDK instalita en la ujo (simila dosiero de via propra dosierujo kun IDEA-agordoj povas esti prenita kiel bazo):

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>

La finita bildo havebla ĉe Docker Hub.

Antaŭ ol daŭrigi, ni kontrolu, ke la IDEA-analizilo funkcias en la ujo:

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

La analizo devus funkcii sukcese, kaj multaj .xml dosieroj kun analizilo-raportoj aperu en la subdosierujo target/idea_inspections.

Nun ne plu estas dubo, ke la IDEA-analizilo povas funkcii memstare en iu ajn CI-medio, kaj ni pluiras al la dua paŝo.

Paŝo 2. Montru kaj analizu la raporton

Akiri la raporton en la formo de .xml dosieroj estas duono de la batalo nun vi devas fari ĝin homlegebla; Kaj ankaŭ ĝiaj rezultoj estu uzataj en kvalitaj pordegoj - la logiko por determini ĉu la akceptita ŝanĝo pasas aŭ malsukcesas laŭ kvalitkriterioj.

Ĉi tio helpos nin Jenkins Warnings NG Kromaĵo, kiu estis liberigita en januaro 2019. Kun ĝia alveno, multaj individuaj kromprogramoj por labori kun statikaj analizrezultoj en Jenkins (CheckStyle, FindBugs, PMD, ktp.) nun estas markitaj kiel malnoviĝintaj.

La kromaĵo konsistas el du partoj:

  • multaj analizaj mesaĝkolektantoj (kompleta listo inkluzivas ĉiujn analizilojn konatajn de scienco de AcuCobol ĝis ZPT Lint),
  • ununura raportspektanto por ĉiuj ili.

La listo de aferoj kiujn Warnings NG povas analizi inkluzivas avertojn de la Java-kompililo kaj avertojn de Maven-ekzekutaj protokoloj: kvankam ili estas konstante videblaj, ili malofte estas specife analizitaj. IntelliJ IDEA-raportoj ankaŭ estas inkluditaj en la listo de agnoskitaj formatoj.

Ĉar la kromaĵo estas nova, ĝi komence bone interagas kun Jenkins Pipeline. La konstrupaŝo kun ĝia partopreno aspektos tiel (ni simple diras al la kromaĵo, kian raportformaton ni rekonas kaj kiajn dosierojn estu skanitaj):

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

La raporta interfaco aspektas jene:

Kurante IntelliJ IDEA-inspektadojn sur Jenkins

Oportune, ĉi tiu interfaco estas universala por ĉiuj agnoskitaj analiziloj. Ĝi enhavas interagan diagramon de la distribuo de trovaĵoj laŭ kategorio kaj grafeon de la dinamiko de ŝanĝoj en la nombro da trovaĵoj. Vi povas fari rapidan serĉon en la krado ĉe la malsupro de la paĝo. La nura afero, kiu ne funkciis ĝuste por IDEA-inspektadoj, estis la kapablo foliumi kodon rekte en Jenkins (kvankam por aliaj raportoj, ekzemple Checkstyle, ĉi tiu kromaĵo povas fari tion bele). Ŝajnas, ke ĉi tio estas cimo en la IDEA raporta analizilo, kiu devas esti riparita.

Inter la trajtoj de Warnings NG estas la kapablo kunigi trovojn de malsamaj fontoj en unu raporto kaj programi Quality Gates, inkluzive de "kliko" por la referenca asembleo. Iu Quality Gates-programa dokumentaro estas havebla tie - tamen ĝi ne estas kompleta, kaj vi devas rigardi la fontkodon. Aliflanke, por kompleta kontrolo de tio, kio okazas, la "kliko" povas esti efektivigita sendepende (vidu mian antaŭa afiŝo pri ĉi tiu temo).

konkludo

Antaŭ ol komenci prepari ĉi tiun materialon, mi decidis serĉi: ĉu iu jam skribis pri tiu ĉi temo pri Habré? Mi nur trovis intervjuo 2017 с lanykie li diras:

Kiom mi scias, ne ekzistas integriĝo kun Jenkins aŭ maven-kromaĵo […] Principe, ajna entuziasmulo povus amikiĝi kun IDEA Community Edition kaj Jenkins, multaj nur profitus el tio.

Nu, du jarojn poste ni havas Warnings NG Plugin, kaj finfine ĉi tiu amikeco realiĝis!

fonto: www.habr.com

Aĉetu fidindan gastigadon por retejoj kun DDoS-protekto, VPS-VDS-serviloj 🔥 Aĉetu fidindan retejan gastigadon kun DDoS-protekto, VPS VDS-servilojn | ProHoster