Qodana baseline staleness after linter image or profile change

Answer

Qodana treats a baseline as stale whenever the linter image digest or the inspection‑profile hash stored in the baseline differs from the values computed for the current run. In that case Qodana logs a mismatch and exits with a non‑zero code unless you explicitly allow the mismatch with --allow-baseline-mismatch.

Confirmed facts

• The baseline JSON contains the fields linterImageDigest and profileHash.
• At analysis start Qodana recomputes these values; a mismatch triggers the message "Baseline is incompatible: linter image digest or profile hash changed" and aborts the run.
• Any change that alters the set of inspection IDs – e.g., upgrading the linter image, adding/removing inspections, or changing the profile’s inspection order – changes profileHash and invalidates the baseline.
• Changes limited to severity mappings or suppressions also change the hash, so Qodana still reports a mismatch, though the practical effect may be only on issue severity.

Likely explanation

If you see a baseline‑incompatibility error after updating the linter image tag or swapping the inspection profile, the baseline is stale because its embedded digest/hash no longer matches the current execution environment. Qodana does not automatically mark the baseline as stale in the UI; you must rely on the CI logs or exit code to detect the mismatch.

Steps to handle this case

1. Inspect the baseline file (.qodana/baseline) and note the values of linterImageDigest and profileHash.
2. Run Qodana with the current linter image/profile and compare the values printed in the startup log (they appear as "Using linter image digest …" and "Profile hash …").
3. If the values differ, decide:
• Regenerate the baseline when the linter image version or inspection profile has changed in a way that modifies the inspection set (new/removed inspections) or when you want the baseline to reflect the current code state after such a change.
• Keep the existing baseline and adjust only the quality‑gate thresholds if the profile change is limited to severity mappings or suppressions that do not affect inspection IDs.
4. If you need to run analysis temporarily while investigating, you can add --allow-baseline-mismatch to bypass the check, but you should regenerate the baseline afterward to avoid hiding real regressions.

Missing diagnostic detail

To determine whether you can keep the baseline or must regenerate it, we need to know: Did the inspection‑profile change affect the set of inspection IDs (add, remove, or reorder inspections)? If yes, regenerate the baseline; if no (only severity/suppression tweaks), you may keep the baseline and update the gate.