Inspection profiles
Inspection profiles define inspections, file scopes that these inspections analyze, and inspection severities. This section explains how you can use existing Qodana profiles, create your own profiles, and set up profiles for analyzing your projects using Qodana.
Existing Qodana profiles
Out of the box, you can use the following Qodana profiles:
Profile name | Description |
|---|---|
| The subset of the |
| Implements default profiles of JetBrains IDEs like IntelliJ IDEA with the following exceptions:
|
| This profile is enabled by default to analyze whether a project is configured properly. If To learn how disable inspections of this profile, see the Disable sanity checks and Profile sections. |
These profiles are hosted on GitHub, so you can learn them in detail.
Set up an existing profile
A YAML configuration serves as a universal Qodana configuration method. This means that you can configure Qodana using the qodana.yaml file once and then reuse it for running Qodana with Docker, GitHub, JetBrains IDEs or any other software currently supported by Qodana. The settings will remain consistent across all these platforms.
To set up the qodana.recommended profile, in the project root save the qodana.yaml file containing the following configuration:
In your IDE, navigate to .
On the
profilesection of the dialog, paste the profile configuration:profile: name: qodana.recommended
On the dialog, check the option.
Click to start analyzing your code.
On the tab of the GitHub UI, create the
QODANA_TOKENencrypted secret and save the project token as its value.On the tab of the GitHub UI, set up a new workflow and create the
.github/workflows/code_quality.ymlfile.To analyze the
mainbranch, release branches and the pull requests coming to your repository, save the workflow configuration to the.github/workflows/code_quality.ymlfile:name: Qodana on: workflow_dispatch: pull_request: push: branches: # Specify your branches here - main # The 'main' branch - 'releases/*' # The release branches jobs: qodana: runs-on: ubuntu-latest permissions: contents: write pull-requests: write checks: write steps: - uses: actions/checkout@v3 with: ref: ${{ github.event.pull_request.head.sha }} # to check out the actual pull request commit, not the merge commit fetch-depth: 0 # a full history is required for pull request analysis - name: 'Qodana Scan' uses: JetBrains/qodana-action@v2025.2 with: args: --profile-name,qodana.recommended env: QODANA_TOKEN: ${{ secrets.QODANA_TOKEN }}Here, the
--profile-nameoption specifies theqodana.recommendedprofile.
You can set up the qodana.recommended profile using the --profile-name option:
Custom profiles
You can create custom profiles using the following formats:
YAML is the preferred format
XML can be used as an alternative to YAML
Custom profiles can either override existing profiles or be created from scratch. For example, to use the existing qodana.recommended profile and additionally enable the Java/Java language level migration aids inspection category, save this YAML configuration in the profile file:
You can also store profile configurations in dedicated files and attach them using the imports block. In this case, it is advised to save them in the .qodana/profiles directory of your project. If you run Qodana in a CI/CD pipeline and store profile configurations in a separate file, make sure that such file resides in the working directory where the VCS stores your project before building it.
Create your profile
This snippet demonstrates how you can fine-tune Qodana to fit your needs.
This snippet consists of several nodes:
Section | Description |
|---|---|
The profile that will serve as a basis for your profile configuration | |
Name of the inspection profile | |
Include an existing file-based profile into your profile | |
Inspection groups that need to included or excluded in your profile | |
List of changes applied for |
baseProfile
The baseProfile block lets you specify the profile that will serve as a basis for your profile configuration. It can accept the following values:
| Description |
|---|---|
| The default profile taken from the JetBrains IDE |
| The profile is basically similar to |
| Any name of an XML or YAML profile contained in the |
| The default Qodana profile, a subset of the |
| The default Qodana profile implementing the default profiles of JetBrains IDEs |
| Severities and parameters of inspections are taken from |
If this parameter is missing, Qodana will employ the Project Default profile, so all settings applied in your custom profile will override such settings contained in Project Default.
name
Arbitrary name for your profile.
imports
Contains the list of relative paths to imported profiles.
The imports block is not related to baseProfile. If baseProfile contains no values, it is set to Default.
To view the default profile, in the JetBrains IDE navigate to Settings | Editor | Inspections and select the Default profile in the Profile drop-down selector.
File contents are included in the order of appearance, thus becoming part of your profile. This means that the settings of the included files are used prior to the settings specified in your custom profile.
Example
Suppose, you have the foo.yaml and bar.yaml profiles.
The foo.yaml profile enables the Inspection1, Inspection2 and Inspection3 inspections:
The bar.yaml profile disables the Inspection1 inspection:
You can include these two files in the custom profile and disable Inspection2:
In this case, the effective profile configuration read by Qodana will look like this:
groups
The groups block is a list of user-defined groups. Here, you can combine inspection categories and single inspections, and then configure their usage in the inspections block.
Each group definition can include or exclude other groups or single inspections.
You can use the exclamation mark character (!) to negate a group or a category. For example, you can exclude a specific category usage in a group that will be included.
Here is the sample containing the EnabledInspections group defined by a user:
This sample contains the following properties:
Property | Description |
|---|---|
ID of the group | |
List of included and excluded inspections in this group | |
List of included and excluded groups in this group |
groups.groupId
Unique group identifier.
In case two groups are defined under the same groupId, the latest group met in the file will be employed. This rule also works for all included files because the settings contained in the included files are considered prior to the settings laid out in the current file.
groups.inspections
The list of inspections included in the group.
groups.groups
The list of group IDs with possible exclamation mark character (!):
Here, groups lists several values:
| Description |
|---|---|
| Include all inspections. Besides that, you can also use |
| Name of the inspection category in the |
| Name of the existing user-defined group, or a group from an included profile |
| Negate the existing |
| Include or exclude inspections by a certain severity level. Because the severity value is taken from the |
By default, Qodana uses severity levels inherited from the JetBrains IDEs shown in this table:
IDE severity | SARIF severity | Qodana report severity | Code Climate severity | Bitbucket severity |
|---|---|---|---|---|
ERROR | ERROR | Critical | Blocker | High |
WARNING | WARNING | High | Critical | High |
WEAK WARNING | NOTE | Moderate | Major | Medium |
TYPO | NOTE | Low | Minor | Low |
INFORMATION | NOTE | Info | Info | Info |
OTHER | NOTE | Info | Info | Info |
inspections
Using inspections, you can:
Enable or disable a specific group or an inspection,
Define the order of applying these settings,
Define the paths or scopes to be ignored by the specific group or the inspection,
Customise severity for specific inspections or inspection groups,
Configure inspection options.
This sample contains several properties:
Property | Description |
|---|---|
| The ID of the group from the |
| The ID of the inspection |
| Severity level that will be assigned to a group of inspections or a single inspection. For example, you can specify |
| List of paths using the glob patterns and scopes that will be ignored during inspection |
| Specify whether the group or the inspection is enabled in the profile. Accepts either |
| List of options that you can configure for a specific inspection |
Examples
Here you can find several examples of profile configuration.
Exclude inspection
This lets you exclude the PhpDeprecationInspection inspection available in the Qodana for PHP linter:
Alternatively, you can exclude the PhpDeprecationInspection inspection using groups:
Exclude paths
You can use the ignore block to ignore specific scopes and paths while inspecting your code.
In the sample below, the vendor/** value employs glob patterns for ignoring the contents of the vendor directory contained in your project root.
The scope definition scope#file:*.js:testData//* ignores all files with the .js extension recursively contained in the testData/ directory.
Create profile
Using baseProfile, this configuration defines the empty profile, and then it includes only the Java/Data flow inspection group from the Qodana for JVM linter.
As an alternative to baseProfile, you can use ALL in the groups property:
Override profile
You can exclude inspection categories from the qodana.starter profile that are not related to the Qodana for .NET linter.
Filter by severity
This sample includes all inspections with the WEAK WARNING severity level while inspecting Java code:
Override severity
You can override the severity levels for existing inspections. Here’s how you can assign the WARNING severity level to the JavadocReference inspection:
Override options
Specific inspections offer configurable options. For example, the JvmCoverageInspection inspection offers the classThreshold, methodThreshold, and warnMissingCoverage options.
To discover this, configure this inspection in IntelliJ IDEA and then export the profile. Here is a profile example for the JvmCoverageInspection inspection:
This sample demonstrates how to configure the inspection options in your custom profile:
Custom XML profiles
You can create XML-formatted inspection profiles using your IDE. For example, for IntelliJ IDEA this is explained on the Configure profiles page. After you create a profile, you can export it to a file.
To run Qodana with the custom profile, you can follow the recommendations from the Set up an existing profile section. In this case, the profile name does not necessarily match the name of the containing file. The actual name is stored as the %profileName% value in the profile file.
Use your profile
A YAML configuration serves as a universal Qodana configuration method. This means that you can configure Qodana using the qodana.yaml file once and then reuse it for running Qodana with Docker, GitHub, JetBrains IDEs or any other software currently supported by Qodana. The settings will remain consistent across all these platforms.
Depending on your needs, specify a profile configuration or path to a file containing the profile configuration:
The following examples show how you can use configurations stored in files:
On the tab of the GitHub UI, create the
QODANA_TOKENencrypted secret and save the project token as its value.On the tab of the GitHub UI, set up a new workflow and create the
.github/workflows/code_quality.ymlfile.To analyze the
mainbranch, release branches and the pull requests coming to your repository, save the workflow configuration to the.github/workflows/code_quality.ymlfile:name: Qodana on: workflow_dispatch: pull_request: push: branches: # Specify your branches here - main # The 'main' branch - 'releases/*' # The release branches jobs: qodana: runs-on: ubuntu-latest permissions: contents: write pull-requests: write checks: write steps: - uses: actions/checkout@v3 with: ref: ${{ github.event.pull_request.head.sha }} # to check out the actual pull request commit, not the merge commit fetch-depth: 0 # a full history is required for pull request analysis - name: 'Qodana Scan' uses: JetBrains/qodana-action@v2025.2 with: args: --profile-path,.qodana/profiles/<custom-profile.yaml> env: QODANA_TOKEN: ${{ secrets.QODANA_TOKEN }}Here, the
--profile-pathoption specifies the relative path to the file containing a custom profile.
You can set up your custom profile using the --profile-path option:
Order of resolving a profile
Qodana checks the configuration parameters for resolving the inspection profile in this order:
Profile with the name
%name%from the command-line option--profile-name %name%Profile by the path
%path%from the command-line option--profile-path %path%Profile with the name
%name%fromqodana.yamlProfile by the path
%path%fromqodana.yamlProfile mounted to
/data/profile.xmlFall back to using the default
qodana.recommendedprofile.