Kotlin
Code Analysis
Configuration - .deepsource.toml
This section covers configuration specific to the Kotlin
analyzer. Please make sure to read the general configuration guide first.
name
- Type: String
- Presence: mandatory
- Description: Shortcode of the analyzer.
- Example:
enabled
- Type: Boolean
- Presence: optional
- Description: Toggle whether this analyzer should be run.
- Example:
meta
- Type: Table
- Presence: optional
- Description: Any supported metadata to pass to the analyzer.
- Example:
language_version
- Type: String
- Presence: optional
- Description: The version of Kotlin that is being used by your project. This information is used to fine-tune the analysis and report issues that are more relevant to the mentioned version of Kotlin.
- Available Values:
1.0
,1.1
,1.2
,1.3
,1.4
,1.5
,1.6
,1.7
,1.8
,1.9
- Default Value: “1.7”
- Example:
runtime_version
- Type: String
- Presence: optional
- Description: The version of Java runtime to use. This information is used to fine-tune the analysis and report issues that are more relevant to the Java runtime being used.
- Available Values:
1.8
,9
,10
,11
,12
,13
,14
,15
,16
,17
,18
,19
- Default Value: “1.8”
- Example:
cyclomatic_complexity_threshold
- Type: String
- Presence: optional
- Description: Specify the acceptable risk category for your project as the threshold. All functions with complexity beyond this threshold will raise an issue. For example, setting the threshold to
low
will flag all functions that have a cyclomatic complexity of more than5
, while setting the threshold tocritical
will not flag any function. - Available Values:
low
,medium
,high
,very-high
andcritical
Risk category | Cyclomatic complexity range | Recommended action |
---|---|---|
low | 1-5 | No action is needed. |
medium | 6-15 | Review and monitor. |
high | 16-25 | Review and refactor. Recommended to add detailed comments if the function absolutely needs to be kept as it is. |
very-high | 26-50 | Refactor to reduce the complexity. |
critical | >50 | Must refactor this. This can make the code untestable and very difficult to understand. |
- Default Value:
medium
- Example:
Sample config
Code Coverage
The test coverage analyzer supports test coverage metrics for Jacoco and Kover XML reports.
Jacoco
Setting up test coverage differs with each type of build system (Maven, Gradle, etc.). Here’s an example of the configuration needed to run Jacoco on a maven repo:
Once you’ve added Jacoco to your project’s pom.xml
file, you should be able to run tests and generate the coverage report. The default location of the coverage report is target/site/jacoco/jacoco.xml
.
After you have the XML test report, you can upload it to DeepSource using the cli:
In case your project has multiple modules, you will need to use the jacoco:report-aggregate
goal to merge all reports together.
Kover
If you have a gradle project, you can set up kover for report generation as well.
Add the following in your top-level build file:
Once you’ve applied the Kover Gradle plugin, Kover tasks for report generation and verification will be created. To generate XML reports, you can use the following command:
koverXmlReport
will build, execute tests and then write out an XML report in the specified report location. The default location for Kover reports is:build/reports/kover/xml/report.xml
.
Note that kover will automatically run your full test suite by default. If you instead want to execute tests separately, make sure to include
-x test
in gradle’s arguments.
You can then use the DeepSource CLI to upload this report:
Code Formatter (Transformer)
Ktlint
Transform all incoming Kotlin code with Ktlint. Documentation for Ktlint’s .editorconfig
configuration can be found here.
This section covers .deepsource.toml
configuration specific to the ktlint
transformer. Please make sure to read the general configuration guide first.
name
- Type: String
- Presence: mandatory
- Description: Shortcode of this transformer.
- Example:
enabled
- Type: Boolean
- Presence: optional
- Description: Toggle whether this transformer should be run.
- Example:
Vulnerability Scanning
Supported target files:
pom.xml