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?