Configure a Profile via qodana.yaml
Qodana runs are configured via the
qodana.yaml configuration file. Information stored in
qodana.yaml overrides the default inspection profile settings and default configurations of Qodana linters. You can specify such overrides in the HTML report, and the changes are imported to
qodana.yaml automatically. To run subsequent checks with this customized configuration, save the file to the project's root directory. Alternatively, you can edit the
qodana.yaml configuration file manually. This section will guide you through necessary settings.
Set up a profile
Out of the box, Qodana provides several predefined profiles:
qodana.recommended— the default profile containing a preselected set of IntelliJ IDEA Java and Kotlin inspections.
empty— an empty profile containing no inspections, which can be used as a basis for manual configuration.
You can specify other profiles available in the respective IntelliJ Platform IDE for your source project. If you are using a CI system, make sure that the
.xml file with this profile is in the working directory where the VCS stores your project before building it. The IntelliJ IDEA profiles for embedding into Qodana Docker images are hosted in the qodana-profiles GitHub repository.
Set up a profile by the name:
Set up a profile by the path:
Exclude paths from the analysis scope
You can specify that the files in a certain directory are not analyzed. This can be done for a certain inspection or for all inspections.
For all inspections:
For inspections specified by the ID:
You can find specific inspection IDs in the Profile settings in the HTML report or in the
.xml file with your inspection profile.
Include an inspection into the analysis scope
If an inspection is not contained in the selected profile, you can include it into the analysis scope explicitly via the
In this example, the
empty profile, which contains no inspections, is specified, and the
SomeInspectionId inspection is explicitly included into the analysis scope. As a result, only the check performed by the
SomeInspectionId inspection will be included in the Qodana run.
Add a fail threshold to use as a quality gate:
When this number of problems is reached, the container executes
exit 255. Can be used to make the CI step fail. The default value is
An example with different configuration options
In the example above,
SomeInspectionIdinspection is explicitly enabled, although it is disabled in the profile
Annotatorinspection is disabled for all paths
AnotherInspectionIdinspection is disabled for
no inspections are conducted over these paths:
Clone Finder license overrides
You need license overrides when you want to stop seeing warnings about certain mismatched licenses in Clone Finder's reports. For example, Clone Finder's default license compatibility matrix specifies that a queried project with the GPL-3.0-only license may not use code from projects with the ISC license. That's why Qodana Clone Finder will show a warning for duplicate code fragments with such mismatched licenses. However, if your legal advisor says it is OK, you can specify to ignore warnings for this specific license in reference projects. You can do so in the HTML report via the Problem explorer or directly in
qodana.yaml as shown in the example below.
In the example above, using code from ISC reference projects (
target) is allowed in the GPL-3.0-only queried project (
source ), although this combination is listed as incompatible, for example, in choosealicense.com/appendix/.
License Audit configuration
Use license identifiers from the SPDX License List.
Exclude an inspection
By default, Qodana License Audit includes all supported inspections.
Exclude inspections from the analysis:
Allow or prohibit a license
Override the predefined licence compatibility matrix:
key is the project license(s); the dependency licenses are specified in
Override a dependency license
Override a dependency license ID if it has been detected incorrectly:
name is the dependency name,
version is the dependency version, and
licenses — the redefined dependency license(s).
In the example above, you 'tell' License Audit to detect BSD-3-Clause and no other licenses for numpy (only 1.19.1).
Ignore a dependency license
Ignore a dependency license to hide the related problems from the report:
name is the dependency name,
licenses — the list of dependency licenses ignored for the specified dependency.
In the example above, in the analyzed project, the dependency numpy, version 1.19.1 has the GPL-3.0 license (which is supposedly prohibited for this project) and the license for enry (0.1.1) is not recognized. The problems with these dependencies will be ignored in the reports, and you won't see the prohibited and unrecognized license problems you've seen before.
By default, Qodana License Audit looks for package manager manifests on the given project root. If you have applications with different package managers declared in subdirectories, use
paths to specify such subdirectories relative to your project root.
If you want to scan both specific paths for package manager manifests and the root of your project, include
. to the list of paths (for root).
By default, Qodana License Audit runs Gradle with
runtimeClasspath configurations. You can specify the wanted Gradle configurations in
By default, npm or yarn exclude all non-development dependencies. To include development or test dependencies, put
all to the configuration.
Other package managers supported do not allow specifying the scopes.
Default detector options:
thresholdis the license detection threshold value from 0.0 to 1.0
includeTextspecifies whether to add the license text by which the license ID was recognized to the report or not
deepspecifies whether to run a deep license detection: check every file and always detect licenses from dependencies, even when they were declared on the package level