I am running Sonarqube 8.3 Developer edition
I was excited to get Developer edition and start running feature branch based scans. However, a strange thing I noticed was that if I had a failing Quality Gate all i would have to do to resolve this and have the QG pass would be to run the build again.
After some digging I think this is caused by the fact that every build we do has a new version number - this allows traceability of any artefact back to a particular build.
The Code Period just looks at the previous version (in our case, one build prior) when deciding on the QG and so now it passes.
I was expecting to be able to configure Code Period to be able to point to the last version from my master branch but it seems this is not possible.
Reading some topics on this forum i see some suggestions saying people have written some automation to set the Code Period to number of days since the last master scan but this seems clunky. Also, let’s say Code Period is set to 10 days as that’s when my master build was last released. How does SonarQube know to check master branch and not my 10 day old feature branch.
I feel like i’m really missing the mark on how this feature is supposed to work but i really don’t see how Code Period can ever be useful unless it’s referencing the main branch.
How would SonarQube expect this to work when I have a new version number every release? It seems it doesn’t.
https://community.sonarsource.com/t/make-sonar-leak-period-an-analysis-parameter/13798/4
In this post Fabrice Bellingard states
I have the feeling that one root of your difficulties come from how your teams are using the
sonar.projectVersion
property. This property is not meant to design a branch, a tag, or a specific commit. It is supposed to represent the “functional” version of your project (version that is supposed to be updated/changes according to your release cycle).
I think this is a mistake. In a world of CI where any build could produce a release candidate you can’t just arbitrarily choose a “functional version”. Version numbers change, a lot. That said, i could make changes to our pipeline to keep our feature branch version static (at the expense of the rest of our tooling) but does this guarantee that “Previous Version” always means the main branch previous version?