IntelliJ IDEA obecnie posiada najbardziej zaawansowany statyczny analizator kodu Java, który znacznie przewyższa takie "weterany" jak i . Jej liczne "inspekcje" sprawdzają kod pod różnymi kątami, od stylu kodowania po charakterystyczne błędy.
Jednak póki co wyniki analizy wyświetlane są jedynie w lokalnym interfejsie IDE programisty, co niewiele wnosi do procesu rozwoju. Statyczna analiza jako pierwszy krok w procesie budowania, a wyniki analizy powinny określać bramki jakości, a budowa powinna kończyć się niepowodzeniem, jeśli bramki jakości nie są spełnione. Znane jest, że TeamCity CI jest zintegrowany z IDEA. Ale nawet jeśli nie korzystasz z TeamCity, możesz spróbować uruchamiać inspekcje IDEA w dowolnym innym serwerze CI. Proponuję zobaczyć, jak można to zrobić, używając IDEA Community Edition, Jenkins i plugin Warnings NG.
Krok 1. Uruchamiamy analizę w kontenerze i uzyskujemy raport
Na początek pomysł uruchamiania IDE (aplikacji desktopowej!) wewnątrz systemu CI, który nie ma interfejsu graficznego, może wydawać się wątpliwy i bardzo uciążliwy. Na szczęście twórcy IDEA udostępnili możliwość uruchamiania i z poziomu linii poleceń. Ważne, że do uruchomienia IDEA w tym trybie nie jest wymagany graficzny interfejs użytkownika, a te zadania można wykonane na serwerach z interfejsem tekstowym.
Uruchamianie inspekcji odbywa się za pomocą skryptu bin/inspect.sh z katalogu instalacyjnego IDEA. Wymagane są następujące parametry:
- pełna ścieżka do projektu (relatywne nie są wspierane),
- ścieżka do pliku .xml z ustawieniami inspekcji (zwykle znajduje się wewnątrz projektu w .idea/inspectionProfiles/Project_Default.xml),
- pełna ścieżka do folderu, w którym zostaną zapisane pliki .xml z raportami z wynikami analizy.
Dodatkowo oczekuje się, że
- w IDE będzie skonfigurowana ścieżka do Java SDK, inaczej analiza nie będzie działać. Te ustawienia znajdują się w pliku konfiguracyjnym
jdk.table.xmlw folderze globalnej konfiguracji IDEA. Globalna konfiguracja IDEA domyślnie znajduje się w katalogu domowym użytkownika, ale to miejsce w plikuidea.properties. - analizowany projekt musi być ważnym projektem IDEA, dlatego dla systemu kontroli wersji będziesz musiał skomitować pewne pliki, które są zazwyczaj ignorowane, a mianowicie:
.idea/inspectionProfiles/Project_Default.xml— ustawienia analizatora, które będą wyraźnie używane podczas uruchamiania inspekcji w kontenerze,.idea/modules.xml— w przeciwnym razie otrzymamy błąd 'Ten projekt nie zawiera modułów',.idea/misc.xml— w przeciwnym razie otrzymamy błąd 'JDK nie jest poprawnie skonfigurowane dla tego projektu',*.iml-files— w przeciwnym razie otrzymamy błąd dotyczący nie skonfigurowanego JDK w module.
Chociaż zazwyczaj te pliki zawierają .gitignore, nie zawierają żadnych specyficznych informacji o środowisku konkretnego programisty — w przeciwieństwie do, na przykład, pliku workspace.xml, gdzie informacje takie jak ta, są zawarte, i dlatego nie należy go komitować.
Samo nasuwa się rozwiązanie spakowania JDK razem z IDEA Community Edition w kontener w formie gotowej do "natarcia" na analizowane projekty. Wybierzemy odpowiedni bazowy kontener, a oto jaki uzyskamy 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 -v2Dzięki opcji idea.config.path zmusiliśmy IDEA do szukania swojej globalnej konfiguracji w folderze /etc/idea, ponieważ domowy folder użytkownika w warunkach pracy w CI — jest rzeczą nieokreśloną i często w ogóle nieobecną.
Tak wygląda plik kopiowany do kontenera jdk.table.xml, w którym zapisane są ścieżki do OpenJDK, zainstalowanego wewnątrz kontenera (można wziąć jako podstawę podobny plik z własnego katalogu z ustawieniami IDEA):
jdk.table.xml
Obraz w gotowej formie .
Zanim przejdziemy dalej, sprawdzimy uruchomienie analizatora IDEA w kontenerze:
docker run --rm -v :/var/project inponomarev/intellij-idea-analyzerAnaliza powinna przebiec pomyślnie, a w podfolderze target/idea_inspections powinno pojawić się wiele plików .xml z raportami analizatora.
Teraz nie ma już żadnych wątpliwości, że analizator IDEA można uruchomić w trybie offline w dowolnym środowisku CI, przechodzimy do drugiego kroku.
Krok 2. Wyświetlanie i analiza raportu
Uzyskanie raportu w formie plików .xml to dopiero połowa sukcesu, teraz należy go uczynić czytelnym dla człowieka. Wyniki powinny również być wykorzystane w quality gates — logice, która określa, czy wprowadzone zmiany spełniają kryteria jakości.
W tym pomoże nam , której wydanie miało miejsce w styczniu 2019 roku. Po jej pojawieniu się wiele oddzielnych wtyczek do pracy z wynikami statycznej analizy w Jenkins (CheckStyle, FindBugs, PMD itp.) zostało oznaczonych jako przestarzałe.
Wtyczka składa się z dwóch części:
- licznych zbieraczy wiadomości analizatorów ( które obejmują wszystkie znane analizatory od AcuCobol do ZPT Lint),
- oraz wspólnego przeglądarki raportów dla nich.
Wśród tego, co jest w stanie analizować Warnings NG, znajdują się również ostrzeżenia kompilatora Java i ostrzeżenia z logów Maven: choć są one zawsze na widoku, rzadko kiedy analizowane są celowo. Raporty IntelliJ IDEA również znajdują się wśród rozpoznawanych formatów.
Ponieważ wtyczka jest nowa, od samego początku dobrze współpracuje z Jenkins Pipeline. Krok budowy z jej udziałem będzie wyglądać następująco (po prostu informujemy wtyczkę, jaki format raportu rozpoznajemy i które pliki powinny być skanowane):
stage ('Analiza statyczna'){
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')]
)
}Interfejs raportu wygląda tak:
Wygodne jest to, że ten interfejs jest uniwersalny dla wszystkich rozpoznawanych analizatorów. Zawiera interaktywny wykres rozkładu odkryć według kategorii oraz wykres dynamiki zmian liczby odkryć. Na dole strony w gridzie można wykonywać szybkie wyszukiwanie. Jedyną rzeczą, która nie zadziałała poprawnie w raportach IDEA, jest możliwość przeglądania kodu bezpośrednio w Jenkins (choć dla innych raportów, np. Checkstyle, ta wtyczka potrafi to zrobić dobrze). Wydaje się, że to błąd parsera raportów IDEA, który czeka na naprawę.
Wśród możliwości Warnings NG znajduje się możliwość agregowania odkryć z różnych źródeł w jednym raporcie oraz programowania Quality Gates, w tym — „ratchet” dla referencyjnej kompilacji. Niektóre dokumenty na temat programowania Quality Gates są dostępne. — zresztą, nie jest pełna, więc trzeba zaglądać do źródeł. Z drugiej strony, dla pełnej kontroli nad tym, co się dzieje, „katalizator” można wdrożyć samodzielnie (patrz mój na ten temat).
Podsumowanie
Zanim zacząłem przygotowywać ten materiał, postanowiłem poszukać, czy ktoś już pisał na ten temat na Habrze. Znalazłem tylko z , w którym mówi:
O ile mi wiadomo, nie ma integracji z Jenkins lub maven-pluginem […] W zasadzie każdy entuzjasta mógłby połączyć IDEA Community Edition z Jenkins, wielu by na tym zyskało.
Cóż, po dwóch latach mamy Warnings NG Plugin i w końcu to połączenie zostało zrealizowane!
Źródło: habr.com
