Pull Request (PR)
To submit a contribution, create a pull request for this repository. Please make sure that you follow our code style and all tests are passing (all checks must be green).
Custom Rules
If you have an idea for a rule but you are not sure that everyone needs it you can implement a custom rule available only for you. Note that in order to help you, we highly recommend to first follow the Custom Rules 101 tutorial before diving directly into implementing rules from scratch.
Work with us
Would you like to work on this project full-time? We are hiring! Check out https://www.sonarsource.com/hiring
Testing
To run tests locally follow these instructions.
Java versions
You need Java 21
to build the project and Java 17
run the Integration Tests (ITs).
Java 17
can be used to build and test all modules except underjava-checks-test-sources
that requiresJava 21
.Java 21
can be used to build and test all modules except underits
that requiresJava 17
because of SQ imcompatibility.
Build the Project and Run Unit Tests
To build the plugin and run its unit tests, execute this command from the project’s root directory:
mvn clean install
Note that
Running unit tests within the IDE might incur in some issues because of the way the project is built with Maven. If you see something like this:
java.lang.SecurityException: class ... signer information does not match signer information of other classes in the same package
try removing the Maven nature of the ‘jdt’ module.
Integration Tests
To run integration tests, you will need to create a properties file like the one shown below, and set the URL pointing to its location in an environment variable named 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
With for instance the ORCHESTRATOR_CONFIG_URL
variable being set as:
export ORCHESTRATOR_CONFIG_URL=file:///home/user/workspace/orchestrator.properties
Before running the ITs, be sure your MAVEN_HOME environment variable is set.
Sanity Test
The “Sanity Test” is a test that runs all checks against all the test source files without taking into account the result of the analysis. It verifies that rules are not crashing on any file in our test sources. By default, this test is excluded from the build. To launch it:
mvn clean install -P sanity
Plugin Test
The “Plugin Test” is an integration test suite that verifies plugin features such as metric calculation, coverage, etc. To launch it:
mvn clean install -Pit-plugin -DcommunityEditionTestsOnly=true
Note for internal contributors: in order to also execute the tests that depend on the SonarQube Enterprise Edition, use:
mvn clean install -Pit-plugin
Autoscan Test
The tests in the autoscan module are designed to detect differences between the issues the Java analyzer can find with and without bytecode. The goal here is to spot and fix the potential FPs, and verify the expected FNs between that would show up in SonarCloud’s automatic analysis.
Running this test can be broken down in 2 steps:
- Compiling the test sources
- Executing the autoscan test
Compiling the test sources
Make sure that the java-checks-tests-sources
module has been compiled (ie: the .class files in java-checks-tests-sources/target/
are up to date).
In doubt, go the java-checks-tests-sources
module and run:
# Use java 21!
mvn clean compile
Executing the autoscan test
To run the tests, move to the its/autoscan
folder and run:
# cd its/autoscan
# use Java 17!
mvn clean package --batch-mode --errors --show-version \
--activate-profiles it-autoscan \
-Dsonar.runtimeVersion=LATEST_RELEASE
The artifacts produced during the test execution will be found in its/autoscan/target/actual
.
You will want to compare the results produced in the autoscan-diff-by-rules
For more detailed information, you can compare the differences between the results found with bytecode and without bytecode by comparing two respective folders:
Depending on the results found, you might need to update the ground truth. The expected results are listed in src/test/resources.
Debugging Integration Tests
You can debug ITs by adding -Dmaven.binary=mvnDebug
as an option when running the tests. This will cause the analyzer JVM to wait for a debugger to be attached before continuing.