Atualmente, o IntelliJ IDEA possui o analisador de código Java estático mais avançado, que em seus recursos deixou muito para trás "veteranos" como Checkstyle e Spotbugs . Suas muitas "inspeções" verificam o código em vários aspectos, desde o estilo de codificação até os erros característicos.
No entanto, embora os resultados da análise sejam exibidos apenas na interface local do IDE do desenvolvedor, eles são de pouca utilidade para o processo de desenvolvimento. A análise estática deve ser realizada como a primeira etapa do pipeline de montagem, seus resultados devem determinar as portas de qualidade e a montagem falhará se as portas de qualidade não forem aprovadas. O TeamCity CI é conhecido por ser integrado ao IDEA. Mas mesmo se você não estiver usando o TeamCity, tente executar as inspeções da IDEA em qualquer outro servidor de IC. Proponho ver como isso pode ser feito usando o plugin IDEA Community Edition, Jenkins e Warnings NG.
Etapa 1. Execute a análise no contêiner e obtenha um relatório
Inicialmente, a idéia de iniciar um IDE (aplicativo de desktop!) Dentro de um sistema de CI que não possui interface gráfica pode parecer duvidosa e muito problemática. Felizmente, os desenvolvedores do IDEA forneceram a capacidade de executar formatação e inspeção de código na linha de comando. Além disso, para executar o IDEA nesse modo, não é necessário um subsistema gráfico e essas tarefas podem ser executadas em servidores com um shell de texto.
As inspeções são ativadas usando o bin/inspect.sh no diretório de instalação do IDEA. Como os parâmetros são necessários:
- caminho completo para o projeto (parente não suportado)
- caminho para o arquivo .xml com configurações de inspeção (geralmente localizadas dentro do projeto em .idea / inspectionProfiles / Project_Default.xml),
- caminho completo para a pasta na qual os arquivos .xml com relatórios sobre os resultados da análise serão adicionados.
Além disso, espera-se que
- o IDE configurará o caminho para o Java SDK, caso contrário, a análise não funcionará. Essas configurações estão contidas no arquivo de configuração
jdk.table.xml na pasta de configuração global da IDEA. A própria configuração global da IDEA fica por padrão no diretório inicial do usuário, mas esse local pode ser especificado explicitamente no arquivo idea.properties . - o projeto analisado deve ser um projeto válido da IDEA, para o qual o controle de versão precisará confirmar alguns arquivos que geralmente são ignorados, a saber:
.idea/inspectionProfiles/Project_Default.xml - configurações do analisador, elas obviamente serão usadas ao iniciar as inspeções no contêiner,.idea/modules.xml - caso contrário, obtemos o erro 'Este projeto não contém módulos',.idea/misc.xml - caso contrário, obteremos o erro 'O JDK não está configurado corretamente para este projeto',*.iml- - caso contrário, obteremos um erro sobre um JDK não configurado no módulo.
Embora esses arquivos sejam geralmente incluídos no .gitignore , eles não contêm nenhuma informação específica para o ambiente de um desenvolvedor em particular - ao contrário, por exemplo, do arquivo workspace.xml , onde essas informações estão contidas e, portanto, não é necessário confirmá-las.
Por si só, implora uma maneira de empacotar o JDK junto com o IDEA Community Edition em um contêiner, em um formulário pronto para "definir" os projetos analisados. Vamos selecionar o contêiner de base apropriado, e aqui está o arquivo Docker que obtemos:
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
Usando a opção idea.config.path o IDEA a procurar sua configuração global na pasta /etc/idea , porque a pasta inicial do usuário sob condições de IC é uma coisa indefinida e muitas vezes completamente ausente.
É assim que o arquivo jdk.table.xml copiado para o contêiner se parece, no qual os caminhos para o OpenJDK instalado dentro do contêiner são gravados (um arquivo semelhante do seu próprio diretório com configurações de IDEA pode ser utilizado):
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>
A imagem final está disponível no Docker Hub .
Antes de prosseguir, verifique o início do analisador IDEA no recipiente:
docker run --rm -v <///>:/var/project inponomarev/intellij-idea-analyzer
A análise deve funcionar com êxito e vários arquivos .xml com relatórios do analisador devem aparecer na subpasta target / idea_inspections.
Agora não há mais dúvida de que a IDEA pode ser executada offline em qualquer ambiente de IC, e passamos para a segunda etapa.
Etapa 2. Exibir e analisar o relatório
Obter um relatório na forma de arquivos .xml é metade da batalha, agora você precisa torná-lo legível por humanos. E também seus resultados devem ser usados em portões de qualidade - a lógica de determinar se uma mudança aceita passa ou não de acordo com os critérios de qualidade.
Isso nos ajudará ao Jenkins Warnings NG Plugin , lançado em janeiro de 2019. Com sua aparência, muitos plugins individuais para trabalhar com os resultados da análise estática no Jenkins (CheckStyle, FindBugs, PMD etc.) agora estão marcados como obsoletos.
O plug-in consiste em duas partes:
- inúmeros coletores de mensagens do analisador (a lista completa inclui todos os analisadores conhecidos, da AcuCobol ao ZPT Lint),
- um único visualizador para todos eles.
A lista do que o Warnings NG pode analisar inclui avisos do compilador Java e avisos dos logs de tempo de execução do Maven: embora estejam constantemente à vista, raramente são analisados intencionalmente. Os relatórios do IntelliJ IDEA também estão incluídos na lista de formatos reconhecidos.
Como o plug-in é novo, ele inicialmente interage bem com o Jenkins Pipeline. A etapa de montagem com sua participação terá a seguinte aparência (apenas informamos ao plug-in qual formato de relatório reconhecemos e quais arquivos devem ser verificados):
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')] ) }
A interface do relatório fica assim:
Convenientemente, essa interface é universal para todos os analisadores reconhecidos. Ele contém um diagrama interativo da distribuição de descobertas por categoria e um gráfico da dinâmica das mudanças no número de descobertas. Na grade na parte inferior da página, você pode realizar uma pesquisa rápida. A única coisa que o IDEA não funcionou corretamente para as inspeções foi a capacidade de procurar o código diretamente no Jenkins (embora para outros relatórios, como o Checkstyle, esse plug-in possa fazer isso de maneira maravilhosa). Este parece ser um bug do analisador de relatórios da IDEA a ser corrigido.
Entre os recursos do Warnings NG está a capacidade de agregar descobertas de diferentes fontes em um relatório e programar o Quality Gates, incluindo uma catraca para o conjunto de referência. Alguma documentação de programação do Quality Gates está disponível aqui - no entanto, ela não está completa e você deve procurar a fonte. Por outro lado, para controle total sobre o que está acontecendo, a "catraca" pode ser implementada de forma independente (veja meu post anterior sobre este tópico).
Conclusão
Antes de começar a preparar este material, decidi pesquisar: alguém já escreveu sobre este tópico em Habré? Eu só encontrei uma entrevista de 2017 com lany, onde ele diz:
Até onde eu sei, não há integração com Jenkins ou o plug-in [...] maven. Em princípio, qualquer entusiasta poderia fazer amigos com o IDEA Community Edition e o Jenkins, muitos se beneficiariam disso.
Bem: dois anos depois, temos o Warnings NG Plugin e, finalmente, essa amizade se tornou realidade!