Este proyecto Sonarsource es un analizador de código para Java Projects para ayudar a los desarrolladores a producir código limpio. La información sobre el análisis de las características de Java está disponible aquí.
Para proporcionar comentarios (solicitar una función, informar un error, etc.), use el Foro de la Comunidad de Sonar. No olvide especificar el lenguaje (¡Java!), Versión de complemento y versión Sonarqube.
Si tiene una pregunta sobre cómo usar complementos (y los documentos no lo ayudan), también le recomendamos que use el foro de la comunidad.
Para solicitar una nueva función, cree un nuevo hilo en el foro de la comunidad de Sonarqube. Incluso si planea implementarlo usted mismo y enviarlo a la comunidad, inicie primero un nuevo hilo para asegurarse de que podamos usarlo.
Para enviar una contribución, cree una solicitud de extracción para este repositorio. Asegúrese de seguir nuestro estilo de código y todas las pruebas están pasando (todas las verificaciones deben ser verdes).
Si tiene una idea para una regla, pero no está seguro de que todos lo necesiten, puede implementar una regla personalizada disponible solo para usted. Tenga en cuenta que para ayudarlo, recomendamos que primero siga el tutorial de las Reglas 101 personalizadas antes de sumergirse directamente en la implementación de reglas desde cero.
¿Le gustaría trabajar en este proyecto a tiempo completo? ¡Estamos contratando! Echa un vistazo a https://www.sonarsource.com/hiring
Para ejecutar pruebas localmente, siga estas instrucciones.
Necesita Java 22 para construir el proyecto y Java 17 ejecutan las pruebas de integración (ITS).
Java 17 se puede usar para construir y probar todos los módulos, excepto bajo java-checks-test-sources que requiere Java 22 .Java 22 se puede utilizar para construir y probar todos los módulos, excepto bajo its que requiere Java 17 debido a la incompatibilidad SQ.Para construir el complemento y ejecutar sus pruebas unitarias, ejecute este comando desde el directorio raíz del proyecto:
mvn clean install
Ejecutar pruebas unitarias dentro del IDE puede incurrir en algunos temas debido a la forma en que el proyecto se construye con Maven. Si ves algo como esto:
java.lang.SecurityException: class ... signer information does not match signer information of other classes in the same package
Intente eliminar la naturaleza maven del módulo 'JDT'.
Para ejecutar pruebas de integración, deberá crear un archivo de propiedades como el que se muestra a continuación, y establecer la URL que apunta a su ubicación en una variable de entorno llamada 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
Con, por ejemplo, la variable ORCHESTRATOR_CONFIG_URL se está estableciendo como:
export ORCHESTRATOR_CONFIG_URL=file:///home/user/workspace/orchestrator.properties
Antes de ejecutar el ITS, asegúrese de que se establezca su variable de entorno Maven_Home.
La "Prueba de cordura" es una prueba que ejecuta todas las verificaciones contra todos los archivos de fuente de prueba sin tener en cuenta el resultado del análisis. Verifica que las reglas no se bloqueen en ningún archivo en nuestras fuentes de prueba. Por defecto, esta prueba se excluye de la compilación. Para lanzarlo:
mvn clean install -P sanity
La "prueba de complemento" es un conjunto de pruebas de integración que verifica las características del complemento, como el cálculo métrico, la cobertura, etc. para iniciarlo:
mvn clean install -Pit-plugin -DcommunityEditionTestsOnly=true
Nota para contribuyentes internos: para ejecutar también las pruebas que dependen de la edición de Sonarqube Enterprise, use:
mvn clean install -Pit-plugin
La "prueba de decisión" es un conjunto de pruebas de integración que lanza el análisis de una gran base de código, guarda los problemas creados por el complemento en los archivos de informe y luego compara esos resultados con el conjunto de problemas esperados (almacenados como archivos JSON).
Para ejecutar la prueba, primero asegúrese de que se revisen los submódulos:
git submodule update --init --recursive
Luego, asegúrese de que la variable de entorno JAVA_HOME esté configurada para la ejecución de las pruebas de decisión y que apunte a su instalación local de JDK 17. No hacerlo producirá inconsistencias con los resultados esperados.
Desde la carpeta its/ruling , inicie las pruebas de decisión:
mvn clean install -Pit-ruling -DcommunityEditionTestsOnly=true
# Alternatively
JAVA_HOME=/my/local/java17/jdk/ mvn clean install -Pit-ruling -DcommunityEditionTestsOnly=true
Nota para contribuyentes internos: para ejecutar también las pruebas que dependen de la edición de Sonarqube Enterprise, use:
mvn clean install -Pit-ruling
Esta prueba le brinda la oportunidad de examinar los problemas creados por cada regla y asegurarse de que sean lo que esperas. Es muy probable que cualquier regla implementada plantee problemas en los múltiples proyectos que utilizamos como base de código de decisión.
Para una regla recientemente implementada, significa que una primera construcción probablemente fallará, causadas por las diferencias entre los resultados esperados (sin ningún valor para la nueva regla) y los nuevos resultados. Puede inspeccionar estos nuevos problemas buscando archivos que llevan el nombre de su regla ( squid-SXXXX.json ) en la siguiente carpeta:
/path/to/project/sonar-java/its/ruling/target/actual/...
Para las reglas existentes que se modifican, puede esperar algunas diferencias entre los resultados "reales" (del nuevo análisis) y los resultados esperados. Revise cuidadosamente los cambios que se muestran y actualican los recursos esperados en consecuencia.
Todos los archivos json contienen una lista de líneas, indexadas por archivo, explicando dónde se encuentran los problemas planteados por una regla específica. Si/cuando todo se ve bien para usted, puede copiar el archivo con los problemas reales ubicados en:
its/ruling/target/actual/
En el directorio con los problemas esperados:
its/ruling/src/test/resources/
Por ejemplo, usando el comando:
cp its/ruling/target/actual/* its/ruling/src/test/resources/
Las pruebas en el módulo AutoScan están diseñadas para detectar diferencias entre los problemas que el analizador Java puede encontrar con y sin bytecode. El objetivo aquí es detectar y arreglar los FP potenciales, y verificar los FN esperados entre eso aparecería en el análisis automático de Sonarcloud.
Ejecutar esta prueba se puede descomponer en 2 pasos:
Asegúrese de que se haya compilado el módulo java-checks-tests-sources (es decir: los archivos .class en java-checks-tests-sources/target/ están actualizados).
En duda, ve el módulo java-checks-tests-sources y ejecuta:
# Use java 22!
mvn clean compile Para ejecutar las pruebas, muévase a la carpeta its/autoscan y ejecute:
# cd its/autoscan
# use Java 17!
mvn clean package --batch-mode --errors --show-version
--activate-profiles it-autoscan
-Dsonar.runtimeVersion=LATEST_RELEASE Los artefactos producidos durante la ejecución de la prueba se encontrarán en its/autoscan/target/actual . Querrá comparar los resultados producidos en el AutoScan-Diff-by-Rules
Para obtener información más detallada, puede comparar las diferencias entre los resultados encontrados con Bytecode y sin ByTecode comparando dos carpetas respectivas:
Dependiendo de los resultados encontrados, es posible que deba actualizar la verdad del suelo. Los resultados esperados se enumeran en SRC/Test/Resources.
Puede depurar, agregando -Dmaven.binary=mvnDebug como una opción al ejecutar las pruebas. Esto hará que el analizador JVM espere a que se adjunte un depurador antes de continuar.
Copyright 2012-2024 Sonarsource.
Los analizadores SONARQUBE lanzados después del 29 de noviembre de 2024, incluidas las correcciones de parches para versiones anteriores, se publican bajo la Licencia Avalable de SONAR, la versión 1 (SSALV1).
Consulte los archivos individuales para obtener detalles que especifiquen la licencia aplicable a cada archivo. Los archivos sujetos al SSALV1 se anotarán en sus encabezados.