Qodana runs are configured via the
qodana.yaml configuration file contained in the root directory of your project. Configuration settings of
qodana.yaml override 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
The JSON schema for
qodana.yaml is published in the SchemaStore project, which allows for completion and basic validation in IDEs.
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 the necessary settings.
Run custom commands
bootstrap option of
qodana.yaml, Qodana can perform actions before running inspections.
To install a specific package in the Qodana container using the
apt tool, add this line to
To run a script, save the
prepare-qodana.sh script file to the project directory and specify execution in
To learn more about use-cases, see the Prepare your project section.
Set up a profile
Exclude paths from the analysis scope
You can specify that the files in a certain directory are not analyzed. This can be done on a per-inspection basis or for all inspections at once. To exclude all paths in a project from the inspection scope, omit the
Exclude all inspections for specified project paths:
Exclude inspections specified by ID for specified project paths:
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
You can specify that the files in a certain directory are analyzed by an inspection that is not contained in the selected profile. This can be done on a per-inspection basis. To include all paths in a project into the inspection scope, omit the
In this example, the
empty profile, which contains no inspections, is specified, and the
SomeInspectionId inspection is explicitly included in the analysis scope for the
tools directory. As a result, only the check performed by the
SomeInspectionId inspection the
tools directory contents will be included in the Qodana run.
Set a fail threshold
Add a fail threshold to use as a quality gate:
When this number of problems is reached, the container executes
exit 255. This can be used to make a CI step fail. The default value is
Override the default run scenario
You can override the standard Qodana behavior, which can be helpful in the case of the PHP version migration. To inspect your code from this perspective, you can run the
By default, Qodana employs the
default scenario, which means the normal Qodana run equivalent to this setting:
Example of different configuration options
In the example above,
SomeInspectionIdinspection is explicitly enabled for all paths, although it is disabled in the profile
Annotatorinspection is disabled for all paths
AnotherInspectionIdinspection is disabled for
no inspections are conducted over these paths:
Specify a linter
linter option, you can specify the linter that you are going to employ. For example:
Configure the JDK version
You can configure the JDK version for these linters:
projectJDK option to specify the JDK version, for example:
You can also specify JDK using the name:
To learn more about configuring JDK, see the Configure the JDK section.
Configure the PHP version
You can configure the PHP version before running the Qodana for PHP linter:
Disable sanity checks
By default, sanity checks are enabled in Qodana. You can disable them using this snippet:
Configure the License audit
You can run the License audit feature by enabling the
Ignore a dependency
Ignore a dependency to hide the related problems from the report:
name is the dependency name to ignore.
In the example above, the
enry dependency is completely excluded from the analysis. Because any possible license-related problems are dismissed, the dependency won't be included in the report at all. This is useful to quickly hide internal dependencies that do not need to be mentioned in the report.
Allow or prohibit a license
Override the predefined license compatibility matrix:
keys is the project license(s); the dependency licenses identifiers are specified in
Override a dependency license
Override a dependency license identifier:
name is the dependency name,
version is the dependency version, and
licenses is the list of redefined dependency licenses.
In the example above, you 'tell' Qodana to detect CDDL-1.1, GPL-2.0-with-classpath-exception and no other licenses for jaxb-runtime (only 2.3.1). This is useful when a dependency is dual-licensed, and you want to omit some license or when it's not possible to detect the license from the dependency sources correctly.
Currently, the license audit with Qodana is possible only for JPS, Maven, Gradle, npm, yarn and composer projects. If you want to include the dependency that should be mentioned in the report but is impossible to detect from the project sources, you can use
customDependencies to specify it:
You can specify the plugins that will be downloaded and invoked during inspection.
Plugin cache is stored in the
To install third-party software required for your plugins, you can: