Transitioning from SonarCloud to Qodana: Baseline Management Questions

[rcdailey]

Hello everyone,

I’m currently using SonarCloud to manage code quality, where "new code" is defined as any code committed since the last release (tag). The setup was straightforward, thanks to the Sonar CLI tooling that allows me to specify a version number for each run, automating the process effectively.

Now, I am in the process of transitioning to Qodana, and while I've done extensive reading on its baseline functionality—particularly regarding its integration with GitHub Actions—I find the setup a bit complicated and frustrating for a few reasons:

1. The flexibility in managing the baseline state is valuable, but it places the responsibility on users to determine how to persist that state, which can be cumbersome.
2. One solution I encountered suggests storing the baseline JSON file in the repository, which I find inappropriate and undesirable.

With these concerns in mind, I have a few specific questions:

• What is the best way to replicate the "New Code" semantics from SonarCloud in Qodana?
• How can I avoid the need to store baseline state files in my Git repository? Is there a built-in method for the GitHub Action to handle persistence of that file?
• In terms of CI workflow, how can I set this up to establish a baseline for each stable release? Would I need a separate workflow to build a baseline for every tag pushed, or is there an alternative approach?

I appreciate any insights or guidance you can provide. Thank you in advance for your help!

[brichbash]

Hello,

What is the best way to replicate the "New Code" semantics from SonarCloud in Qodana?

Currently, if you add problems to the baseline, all problems that are not in the baseline will be treated as "new". You don't necessarily need to do that via UI, if you pass the qodana.sarif.json file (stored under ${{ runner.temp }}/qodana/results) produced by Qodana and pass it to the --baseline flag, all problems from the file will go to baseline in the next report.

How can I avoid the need to store baseline state files in my Git repository? Is there a built-in method for the GitHub Action to handle persistence of that file?

There isn't any built-in feature like that. Although we're looking into storing baseline files on Qodana Cloud.

In terms of CI workflow, how can I set this up to establish a baseline for each stable release? Would I need a separate workflow to build a baseline for every tag pushed, or is there an alternative approach?

I'd say, you could create a conditional step that is triggered only by the release event that uploads the qodana.sarif.file file as an artifact after the Qodana step. And then set up the Qodana step to use that file as baseline using the --baseline path/to/qodana.sarif.json argument.

[rcdailey]

Thanks; your third answer sort of answers my second question as well. I was thinking either artifact or cache, which are pipeline specific features and don't require storing in the git repo. But I'd have to refresh my memory on 1) if those artifacts/cache can be used across workflows and 2) what the lifecycle of those are.

In all honesty, while Qodana seems to show promise, it seems like it may still be too early to use it for my use case. The amount of work I'd be doing to replace SonarCloud seems a bit much for my taste so far.

I really appreciate your help!

[zheleznovster]

Hi, I have the same question - what is the best way to replicate the "New Code" semantics from SonarCloud in Qodana?

It is not quite the same to add new problems to the baseline - it's new code I'm concerned with, not new types of problems to detect.

While it's useful to see total coverage of the project, it is also very useful to see coverage for only new code introduced in a pull request.

Is there a feature like that, and if not, is there one on the roadmap?

[njimenezotto]

In the company I work we are also very interested on this feature.
Any roadmap to show?
Thanks!