YAML file
By default, Qodana reads configurations from the qodana.yaml
file contained in the root directory of your project. You can override this filename using the --config
option, see the Custom configuration file section. For convenience, this will be referred in this section using the default qodana.yaml
name.
Configuration applied in qodana.yaml
override the default inspection profile settings and default configurations of Qodana linters, you can configure it using the HTML report section, and all changes will be applied automatically.
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 in the root directory of your project. Alternatively, you can edit the qodana.yaml
configuration file manually. This section will guide you through the necessary settings.
note
The configuration saved in the
qodana.yaml
file affects only Qodana linters and does not impact other products, such as IntelliJ IDEA or PhpStorm.
warning
It is highly recommended not to store tokens, passwords, or any other secret information in the
qodana.yaml
file.
Using the bootstrap
key of qodana.yaml
, Qodana can perform actions before running the analysis.
To install a specific package in the Qodana container using the apt
tool, add this line to qodana.yaml
:
bootstrap: apt install <package_name>
To run a script, save the prepare-qodana.sh
script file in the project directory and specify execution in qodana.yaml
:
bootstrap: sh ./prepare-qodana.sh
To learn more about use-cases, see the Prepare your project section.
Profile invocation is explained in the Inspection profiles section. Information about custom profiles is also provided here.
You can exclude files and paths from analyses on a per-inspection basis and for all inspections at once. Information about inspection IDs is available on the Inspectopedia website.
To exclude all paths in a project from the analysis scope, omit the paths
node.
note
Starting from version 2022.3, if using the
qodana.recommended
andqodana.starter
profiles, Qodana reads.gitignore
files of your project and defines the files and folders to be ignored during the analysis.
Exclude all inspections for specified project paths:
exclude:
- name: All
paths:
- asm-test/src/main/java/org
- asm/Visitor.java
- benchmarks
Exclude inspections specified by ID for specified project paths:
exclude:
- name: Annotator
- name: AnotherInspectionId
paths:
- relative/path
- another/relative/path
- name: All
paths:
- asm-test/src/main/java/org
- asm
- benchmarks
- tools
You can find specific inspection IDs in the Profile settings in the HTML report or in the .xml
file with your inspection profile.
You can tell Qodana to analyze files of a certain directory 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 paths
node. Information about inspection IDs is available on the Inspectopedia website.
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.
profile:
name: empty
include:
- name: SomeInspectionId
paths:
- tools
You have several options to configure quality gates.
You can add a fail threshold to control the total number of problems in a project, which is supported by all linters:
failThreshold: <number>
note
When running in the baseline mode, a threshold is calculated as the sum of new and absent problems. Unchanged results are ignored.
All linters except Qodana Community for .NET let you use the following configuration:
failureConditions:
severityThresholds:
any: <number> # Total problems
critical: <number> # Critical and other severities
high: <number>
moderate: <number>
low: <number>
info: <number>
testCoverageThresholds:
fresh: <number> # Fresh code coverage
total: <number> # Total code coverage
In this configuration, exceeding just one setting limitation will make the build fail.
The severityThresholds:any
option lets you configure the total number of problems. Options like severityThresholds:critical
let you configure quality gates for each problem severity. The testCoverageThresholds:fresh
and testCoverageThresholds:total
options let you configure the total and fresh code coverage supported by several linters.
script:
name: <script-name>
parameters:
<parameter>: <value>
You can override the standard Qodana behavior, which can be helpful in case of the PHP version migration. To inspect your code from this perspective, you can run the php-migration
scenario.
By default, Qodana employs the default
scenario, which means the normal Qodana run equivalent to this setting:
script:
name: default
version: 1.0
failThreshold: 0
profile:
name: qodana.recommended
include:
- name: SomeInspectionId
exclude:
- name: Annotator
- name: AnotherInspectionId
paths:
- relative/path
- another/relative/path
- name: All
paths:
- asm-test/src/main/java/org
- benchmarks
- tools
In the example above,
SomeInspectionId
inspection is explicitly enabled for all paths, although it is disabled in the profileAnnotator
inspection is disabled for all pathsAnotherInspectionId
inspection is disabled forrelative/path
andanother/relative/path
no inspections are conducted over these paths:
asm-test/src/main/java/org
,benchmarks
,tools
Using the linter
option, you can specify a linter that you are going to employ. For example:
linter: jetbrains/qodana-jvm-android:2024.3
You can configure the JDK version for these linters:
Use the projectJDK
option to specify the JDK version, for example:
projectJDK: 11
or:
projectJDK: 1.8
You can also specify JDK using the name:
projectJDK: corretto-19
To learn more about configuring JDK, see the Configure the JDK section.
You can configure the PHP version before running the Qodana for PHP linter:
php:
version: "X.x"
By default, sanity checks are enabled in Qodana. You can disable them using this snippet:
disableSanityInspections: true
Starting from version 2024.1 of Qodana, the license audit feature is enabled by default. You can disable it by excluding the CheckDependencyLicenses
inspection:
exclude:
- name: CheckDependencyLicenses
Ignore a dependency to hide the related problems from the report:
dependencyIgnores:
- name: "enry"
where 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.
Override the predefined license compatibility matrix:
licenseRules:
- keys:
- "PROPRIETARY-LICENSE"
- "MIT"
prohibited:
- "BSD-3-CLAUSE-NO-CHANGE"
allowed:
- "ISC"
- keys: [ "Apache-2.0" ]
prohibited:
- "MIT"
In this configuration, keys
is the project license(s) and the dependency licenses identifiers are specified in allowed
or prohibited
.
Override a dependency license identifier:
dependencyOverrides:
- name: "jaxb-runtime"
version: "2.3.1"
url: "https://github.com/javaee/jaxb-v2"
licenses:
- key: "CDDL-1.1"
url: "https://github.com/javaee/jaxb-v2/blob/master/LICENSE"
- key: "GPL-2.0-with-classpath-exception"
url: "https://github.com/javaee/jaxb-v2/blob/master/LICENSE"
where 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. To include the dependency that should be mentioned in the report but is impossible to detect from the project sources, use customDependencies
to specify it:
customDependencies:
- name: ".babelrc JSON Schema (.babelrc-schema.json)"
version: "JSON schema for Babel 6+ configuration files"
licenses:
- key: "Apache-2.0"
url: "https://github.com/SchemaStore/schemastore/blob/master/LICENSE"
Using the fixesStrategy
option, you can choose among the available quick-fix strategies:
fixesStrategy: cleanup/apply
In the qodana.yaml
file, include the PhpVulnerablePathsInspection
inspection into the analysis scope:
include:
- name: PhpVulnerablePathsInspection
Alternatively, you can use the inspections
section of qodana.yaml
:
inspections:
- inspection: PhpVulnerablePathsInspection
enabled: true
In the qodana.yaml
file, include the JvmTaintAnalysis
inspection into the analysis scope:
include:
- name: JvmTaintAnalysis
Alternatively, you can use the inspections
section of qodana.yaml
:
inspections:
- inspection: JvmTaintAnalysis
enabled: true
To start using the Vulnerability checker feature, enable the VulnerableLibrariesGlobal
inspection:
include:
- name: VulnerableLibrariesGlobal
You can specify the plugins that will be downloaded and invoked during inspection.
plugins:
- id: <plugin.id>
Here, <plugin-id>
denotes the Plugin ID from JetBrains Marketplace. For example, for Grazie Professional, the Plugin ID will be com.intellij.grazie.pro
. To find the Plugin ID, on the plugin page click the Overview tab and then navigate to the Additional Information section.
Plugin cache is stored in the /data/cache/plugins
directory.
To install third-party software required for your plugins, you can:
Thanks for your feedback!