which versions are you using: SonarQube Server Developer Edition v10.7 (96327)
how is SonarQube deployed: Helm
what are you trying to achieve: new code analysis to compare current work with previously released version using sonar-scanner cli.
what have you tried so far to achieve this: setting projectVersion
Context: We are using git tags to “release” our semantically versioned software. For example there is a tag called v1.0.0 and that point in history is version 1.0.0. Everything after that is unreleased until there is another version tag. Meanwhile sonarqube is run with every commit to catch things early.
Problems:
If projectVersion is not set then the previously set version tags along to the analysis which has not set it. For example we set v1.0.0 to commit X and now do commits Y and Z. Sonarqube sets version v1.0.0 to analysis/commit Z even though Z is unreleased and not part of v1.0.0.
If we would follow the “pre-version strategy” of having v2.0.0-snapshot version then if that version still fails quality gate due to bad new code, then a developer could just release v2.0.0 and as compared to the “snapshot” version nothing new happened, the new code quality gate will pass. We want the comparison to be against the real version, not snapshot version.
Proposed solution:
Sonarqube should not “move” the last known projectVersion to next analysis but should just keep it empty/not-known/no-version. So that when there actually is a new version v2.0.0 then new code will compare v2.0.0 to v1.0.0 and the commits in the middle will not matter.
Or there is another way without changing our workflow too much?
This has the same behavior as setting the projectVersion. The version sticks to the latest analysis. I set the version to 9:03 analysis but it keeps moving to the latest one.
Hm… When I analyze a new project, and provide no sonar.projectVersion, I can later tag a specific version (manually, through the UI) and it’s not inherited by future analyses.
I’m going to phone a friend who might know this behavior better than I do. If neither of us can sort it out, I’ll flag this for attention from our devs.
With that being said, I think you can get around this by having a new project where sonar.projectVersion never gets set.
so it turns out that not provided isn’t what SonarQube uses when you have an empty project version, it is the project version string.
So if you manually tag an activity with the right version, and tag the next one with not provided… then you should be able to start doing what I outlined above.
Yeah its almost a solution (even though its a hacky one and depends really on one string…).
But what it fails with is that I have “not provided” version failing the quality gate. And then I release a version and magically its new code quality gate is passed. Because I did not change any code, just released the version.
I still think that sonarqube needs to actually implement “not provided” instead of using it as a version string.
I would prefer “not provided” to not behave like a version. That would solve all issues…
I want new code period start after a “version”. Meaning that everything that is after a “version” is new code until an actual version appears. To be more specific, if a new version appears then new code should be between this and previous version. And as soon as new analysis is made which has no version, then new code starts right after latest specified version.
Meaning that we can actually see if code has gone worse after a released version. And if after the released version there is no analysis, then we can actually see if new version made things worse than old version was.
so it turns out that 