Qodana baseline suppression gaps when inspection profiles gain new checks

Direct answer

Yes—when an inspection profile gains new checks, the practical workflow is to regenerate the baseline from that exact updated profile on a reviewed, known-good commit, then treat only post-baseline findings as gate failures. Do not manually merge or extend baseline files to cover the new inspection IDs; there is no supported migration path, and hand-editing fingerprints can suppress unrelated issues.

Likely explanation vs. confirmed constraints

Likely explanation: Baseline entries are matched by inspection identity and code location. Newly activated inspection IDs have no corresponding suppression entries, so patterns that were previously suppressed for older inspections now surface as fresh violations. This is a mapping gap, not evidence that Qodana upgrades baselines automatically.

Confirmed constraints: There is no documented qodana baseline migrate command or equivalent. Baselines are profile-specific, and the documentation does not prescribe a migration strategy when profiles change. Behavior is version-specific and may differ between the CLI and Qodana Cloud.

Steps for this case

1. Pin the updated qodana.yaml or IDE profile to a specific revision.
2. Check out a reviewed, known-good commit.
3. Run analysis with the updated profile but without failing the quality gate.
4. Generate the baseline from that same run and profile. If the baseline is a repository file, commit it. If Qodana Cloud manages baseline state, verify whether the refresh applies to the Cloud project or only the local file.
5. Re-enable the gate and review the delta. Only findings after the baseline generation should fail the build.

Why manual merging is unsafe

Copying suppression entries is only plausible when the inspection ID, file path, and code location are unchanged. For newly activated inspections, there is nothing valid to copy. Fingerprints depend on more than the inspection ID—code movement and profile context can change them—so renaming or duplicating entries can silently suppress unrelated defects.

Cloud vs. CLI behavior

Do not assume Qodana Cloud applies implicit baseline upgrade logic that differs from the CLI. If the gate is Cloud-based, verify whether it consumes a repository baseline file or Cloud-managed state before choosing a refresh procedure.

Verification before committing

• Compare the fresh report against the report produced with the old baseline, grouping by inspection ID to confirm new checks are the only source of failures.
• Diff baseline entries by inspection ID before and after the profile change; confirm there are no entries for the new IDs and no entries were manually rewritten.
• On a scratch branch, add a violation detectable only by a newly enabled inspection and verify it is reported before the baseline refresh and suppressed after.

One missing diagnostic detail

Does your CI gate consume a repository baseline file, Qodana Cloud-managed baseline state, or both? This changes the recommendation: file-based baselines are regenerated locally and committed, while Cloud-managed state may require a different or additional step.

Conservative note: Qodana CLI and Cloud behavior is version-specific. Because current behavior requires verification, confirm the exact baseline generation workflow for your Qodana version before applying it to a production gate.