Code quality and security for Kotlin

This repository contains the SonarQube analyzer for Kotlin. It analyzes Kotlin projects and imports issues from external Kotlin linters (Detekt, ktlint, Android Lint) and test results from Surefire reports.

To learn more about Sonar’s Kotlin analysis, visit the Sonar website.

Features

• 140+ rules (Kotlin and Kotlin Gradle DSL; including 10+ security rules using semantic)
• Metrics (cognitive complexity, cyclomatic complexity, number of lines etc.)
• Import of test coverage reports
• Import of external linters: Detekt, ktLint, AndroidLint

Useful links

• Project homepage
• Issue tracking
• Available rules
• Community Forum

Build

Requirements

• Java 21

Setup

To configure build dependencies, run the following command:

git submodule update --init -- build-logic/common

To always get the latest version of the build logic during git operations, set the following configuration:

git config submodule.recurse true

For more information see README.md of cloud-native-gradle-modules.

Build and run Unit Tests:

./gradlew build dist

Integration Tests

Integration and ruling tests require the source projects submodule:

git submodule update --init its/sources

Run ruling tests (uses SIT — no SonarQube server needed):

./gradlew :its:ruling:integrationTest --info --console=plain --no-daemon

Run plugin tests:

./gradlew :its:plugin:integrationTest --info --console=plain --no-daemon

To run a single ruling test method, e.g.:

./gradlew :its:ruling:integrationTest --info --console=plain --no-daemon --tests "org.sonarsource.kotlin.its.KotlinRulingTest.test_kotlin_corda"

Updating ruling golden files

See docs/integration-tests.md for the golden-file procedure, including the test_kotlin_compiler and test_kotlin_language_server corpora and -DreportAll=true.

Additional sq-integration parameters

The orchestrator-based :its:sq-integration tests additionally support:

• -Dsonar.runtimeVersion=<version> — override the SonarQube version (default: DEV)
• -DcleanProjects=true — force a clean build of the analysed projects
• -DkeepSonarqubeRunning=true — leave the SonarQube instance running after the analysis
• -Dsonar.rulingDebugPort=5005 — attach a debugger to the spawned scanner JVM

Utilities and Developing

Generating/downloading rule metadata

The Gradle task ruleApiGenerateRuleKotlin will download the rule metadata from the RSPEC repository.

For example, execute the following in the project root to fetch the metadata for rule S42:

./gradlew :sonar-kotlin-plugin:ruleApiGenerateRuleKotlin -Prule=S42

If fetching from a branch:

./gradlew :sonar-kotlin-plugin:ruleApiGenerateRuleKotlin -Prule=S4830 -Pbranch=a_branch

Alternatively, you can let the tool auto-detect the branch. If you do not provide a branch, it will look at the PRs open in the RSPEC repository that contain the rule key in their name. If it finds any, you will be presented with a choice of which branch to fetch the metadata from. Points to note about this feature:

• You can also add -PautoSelectBranch if you would like the script to automatically use the first branch it finds, if any, instead of prompting you for an interactive decision.
• You can specify -Pbranch=master to default to master.
• Usually, this feature should work as-is. However, it is possible to run into GitHub's rate limiting, which is lower for unauthenticated API requests. If you store a GitHub API token in the environment variable GH_API_TOKEN, it will be used for all requests to GitHub. Make sure you give the token sufficient rights to fetch details about and search pull requests in the RSPEC repository.

If you want to update all rules' metadata, you can use:

./gradlew :sonar-kotlin-plugin:ruleApiUpdateKotlin

Implementing a new rule

The Gradle task setupRuleStubs will create the commonly required files for implementing a new rule, including usual boilerplate code. It will also put the rule into the list of checks and call ruleApiGenerateRuleKotlin to download the rule's metadata.

To use this task, you need to know the rule key and a fitting name for the check class. For instance, if you want to implement the new rule S42 in the class AnswersEverythingCheck, you can call the following in the root of the project:

./gradlew setupRuleStubs -Prule=S42 -PclassName=AnswersEverythingCheck

To create stubs for Kotlin Gradle DSL rules instead of Kotlin rules, use setupGradleRuleStubs, as in:

./gradlew setupGradleRuleStubs -Prule=S6626 -PclassName=TaskDefinitionsCheck

Updating external linter rule mappings

See this README in the utils.

Visualizing ASTs

If you want a graphical output of ASTs, see this README in the utils for more info on how to convert an AST into a DOT format.

License

Copyright 2018-2025 SonarSource.

SonarQube analyzers released after November 29, 2024, including patch fixes for prior versions, are published under the Sonar Source-Available License Version 1 (SSALv1).

See individual files for details that specify the license applicable to each file. Files subject to the SSALv1 will be noted in their headers.