Using Qodana Baseline to Tame Legacy Code Quality in CI

The Problem: Legacy Noise in Pull Requests

When a codebase already contains hundreds of inspection warnings, every new pull request triggers a flood of existing issues in Qodana reports. Reviewers spend time scrolling past known problems, and the signal‑to‑noise ratio drops, making it hard to spot genuinely new defects.

Thesis: Use a Qodana baseline to accept the current state of the code and let the tool report only violations introduced after that point.

How Baseline Works

Qodana can export the full set of inspection results as a JSON file. When this file is supplied to a later analysis via the -baseline option, the engine marks every issue already present in the file as "accepted". The resulting report therefore contains only new warnings, errors, or security findings.

Creating and Committing a Baseline

1. Run a full Qodana analysis on the current branch (typically main or master).
2. Export the results to a JSON file, for example qodana-baseline.json.
3. Commit that file to the repository so it is version‑controlled and reproducible.

Example command (run in the project root, assuming you have the Qodana CLI installed and appropriate permissions to read sources):

qodana \\n  -l . \\n  -baseline-out qodana-baseline.json \\n  -reportOut htmlReport \\n  -show-report false

The -baseline-out flag tells Qodana to write the baseline JSON. Adjust the -l path to point at your source directory. After the command finishes, verify that qodana-baseline.json exists and contains a JSON array of inspection results.

Using the Baseline in CI

In your CI pipeline, run Qodana again, this time pointing to the committed baseline. The build should fail only if the analysis discovers new issues.

# CI step (example for a Linux agent)
qodana \\n  -l . \\n  -baseline qodana-baseline.json \\n  -reportOut htmlReport \\n  -show-report false

To enforce a zero‑new‑issue policy, add a check that parses the JSON report and ensures the newIssuesCount field (or equivalent) is zero. Many teams simply rely on the exit code: Qodana returns a non‑zero status when any issue of the configured severity is found, and because the baseline suppresses old issues, only fresh problems trigger a failure.

Trade‑offs and Limitations

• The baseline does not mute inspections marked as severe (e.g., certain security checks). Those will still fail the build unless you explicitly suppress them with .ignore patterns or separate suppression files.
• If the codebase undergoes a large refactor that moves or renames files, the baseline may no longer match the current state, potentially hiding newly introduced problems. In such cases, renew the baseline after the refactor is complete.
• Maintaining the baseline file adds a small overhead: you must remember to commit it after each baseline renewal and ensure all agents use the same version.

Actionable Next Steps

1. Run a baseline analysis on your main branch and commit the resulting JSON.
2. Update your CI configuration to invoke Qodana with the -baseline flag pointing to that file.
3. Add a simple gate (exit‑code check or JSON parsing) to fail the build on any new issue.
4. Schedule a baseline renewal—e.g., after each major release or after significant refactoring—to keep the baseline in sync with the evolving code.

By treating the existing quality level as an accepted baseline, teams can focus their review effort on genuine regressions while still tracking overall technical debt over time.