sonar java
8.8.0.37665
Este projeto SonarSource é um analisador de código para projetos Java para ajudar os desenvolvedores a produzir código limpo. Informações sobre a análise dos recursos Java estão disponíveis aqui.
Para fornecer feedback (solicite um recurso, relate um bug, etc.), use o fórum da comunidade do sonar. Por favor, não se esqueça de especificar o idioma (Java!), Versão do plug -in e versão Sonarqube.
Se você tiver uma pergunta sobre como usar o plug -in (e os documentos não o ajudarem), também o incentivamos a usar o fórum da comunidade.
Para solicitar um novo recurso, crie um novo tópico no fórum da comunidade Sonarqube. Mesmo se você planeja implementá -lo e enviá -lo de volta à comunidade, inicie um novo thread primeiro para ter certeza de que podemos usá -lo.
Para enviar uma contribuição, crie uma solicitação de tração para este repositório. Certifique -se de seguir nosso estilo de código e todos os testes estão passando (todas as verificações devem ser verdes).
Se você tem uma ideia para uma regra, mas não tem certeza de que todos precisam, pode implementar uma regra personalizada disponível apenas para você. Observe que, para ajudá -lo, é altamente recomendável seguir o tutorial de 101 regras personalizadas antes de mergulhar diretamente na implementação de regras do zero.
Você gostaria de trabalhar neste projeto em tempo integral? Estamos contratando! Confira https://www.sonarsource.com/hiring
Para executar testes, siga localmente estas instruções.
Você precisa de Java 22 para construir o projeto e Java 17 executa os testes de integração (ITS).
Java 17 pode ser usado para construir e testar todos os módulos, exceto sob java-checks-test-sources que requer Java 22 .Java 22 pode ser usado para construir e testar todos os módulos, exceto sob its que requer Java 17 devido à incompatibilidade do SQ.Para construir o plug -in e executar seus testes de unidade, execute este comando do diretório raiz do projeto:
mvn clean install
Os testes de unidade em execução no IDE podem incorrer em alguns problemas devido à maneira como o projeto é construído com o MAVEN. Se você vir algo assim:
java.lang.SecurityException: class ... signer information does not match signer information of other classes in the same package
Tente remover a natureza maven do módulo 'JDT'.
Para executar testes de integração, você precisará criar um arquivo de propriedades como o mostrado abaixo e definir o URL apontando para sua localização em uma variável de ambiente nomeada ORCHESTRATOR_CONFIG_URL .
# version of SonarQube Server
sonar.runtimeVersion=LATEST_RELEASE
orchestrator.updateCenterUrl=http://update.sonarsource.org/update-center-dev.properties
# The location of the Maven local repository is not automatically guessed. It can also be set with the env variable MAVEN_LOCAL_REPOSITORY.
maven.localRepository=/home/myName/.m2/repository
Com por exemplo, a variável ORCHESTRATOR_CONFIG_URL sendo definida como:
export ORCHESTRATOR_CONFIG_URL=file:///home/user/workspace/orchestrator.properties
Antes de executar o ITS, verifique se sua variável de ambiente maven_home está definida.
O "Teste de Sanidade" é um teste que executa todas as verificações em relação a todos os arquivos de fonte de teste sem levar em consideração o resultado da análise. Ele verifica se as regras não estão travando nenhum arquivo em nossas fontes de teste. Por padrão, este teste é excluído da construção. Para lançá -lo:
mvn clean install -P sanity
O "Plugin Test" é um conjunto de testes de integração que verifica recursos do plug -in, como cálculo métrico, cobertura etc. para iniciá -lo:
mvn clean install -Pit-plugin -DcommunityEditionTestsOnly=true
Nota para colaboradores internos: para também executar os testes que dependem da edição Enterprise Sonarqube, use:
mvn clean install -Pit-plugin
O "teste de decisão" é um conjunto de testes de integração que inicia a análise de uma base de código grande, salva os problemas criados pelo plug -in nos arquivos de relatório e compara esses resultados ao conjunto de problemas esperados (armazenados como arquivos JSON).
Para executar o teste, primeiro verifique se os submódulos estão verificados:
git submodule update --init --recursive
Em seguida, verifique se a variável de ambiente JAVA_HOME está definida para a execução dos testes de decisão e que aponte para a instalação local do JDK 17. Não fazer isso produzirá inconsistências com os resultados esperados.
A partir da pasta its/ruling , inicie os testes dominantes:
mvn clean install -Pit-ruling -DcommunityEditionTestsOnly=true
# Alternatively
JAVA_HOME=/my/local/java17/jdk/ mvn clean install -Pit-ruling -DcommunityEditionTestsOnly=true
Nota para colaboradores internos: para também executar os testes que dependem da edição Enterprise Sonarqube, use:
mvn clean install -Pit-ruling
Este teste oferece a oportunidade de examinar os problemas criados por cada regra e verifique se eles são o que você espera. Qualquer regra implementada provavelmente levantará questões nos vários projetos que usamos como base de código dominante.
Para uma regra recém -implementada, significa que uma primeira construção provavelmente falhará, causada por diferenças entre os resultados esperados (sem nenhum valores para a nova regra) e os novos resultados. Você pode inspecionar esses novos problemas pesquisando arquivos com o nome de sua regra ( squid-SXXXX.json ) na seguinte pasta:
/path/to/project/sonar-java/its/ruling/target/actual/...
Para as regras existentes modificadas, você pode esperar algumas diferenças entre "real" (da nova análise) e os resultados esperados. Revise cuidadosamente as alterações mostradas e atualize os recursos esperados de acordo.
Todos os arquivos json contêm uma lista de linhas, indexadas por arquivo, explicando onde estão localizados os problemas levantados por uma regra específica. Se/quando tudo parecer bom para você, você pode copiar o arquivo com os problemas reais localizados em:
its/ruling/target/actual/
No diretório com os problemas esperados:
its/ruling/src/test/resources/
Por exemplo, usando o comando:
cp its/ruling/target/actual/* its/ruling/src/test/resources/
Os testes no módulo Autoscan foram projetados para detectar diferenças entre os problemas que o analisador Java pode encontrar com e sem bytecode. O objetivo aqui é identificar e consertar o FPS em potencial e verificar o FNs esperado entre isso apareceria na análise automática do SonarCloud.
A execução deste teste pode ser dividida em 2 etapas:
Certifique-se de que o módulo java-checks-tests-sources tenha sido compilado (ou seja: os arquivos .class em java-checks-tests-sources/target/ estão atualizados).
Em dúvida, vá para o módulo java-checks-tests-sources e corra:
# Use java 22!
mvn clean compile Para executar os testes, vá para a pasta its/autoscan e execute:
# cd its/autoscan
# use Java 17!
mvn clean package --batch-mode --errors --show-version
--activate-profiles it-autoscan
-Dsonar.runtimeVersion=LATEST_RELEASE Os artefatos produzidos durante a execução do teste serão encontrados em its/autoscan/target/actual . Você vai querer comparar os resultados produzidos no AutoScan-Diff-By-Rules
Para obter informações mais detalhadas, você pode comparar as diferenças entre os resultados encontrados com o bytecode e sem bytecode comparando duas respectivas pastas:
Dependendo dos resultados encontrados, pode ser necessário atualizar a verdade do fundamento. Os resultados esperados estão listados no SRC/teste/recursos.
Você pode depurar, adicionando -Dmaven.binary=mvnDebug como uma opção ao executar os testes. Isso fará com que a JVM do analisador aguarde a anexo de um depurador antes de continuar.
Copyright 2012-2024 SONARSource.
Os analisadores do Sonarqube divulgados após 29 de novembro de 2024, incluindo correções de patches para versões anteriores, são publicados sob a licença Sonar Source-Alowable versão 1 (SSALV1).
Consulte arquivos individuais para obter detalhes que especificam a licença aplicável a cada arquivo. Os arquivos sujeitos ao SSALV1 serão observados em seus cabeçalhos.
