What is good project versioning practice?In addition, we run sonarqube on every pull request with the main branch. We are currently modifying it manually at the devops pipeline every few months. As a result, I believe Sonarqube will consider all code developed after the last version change to be new code. So, instead of analyzing only modified files in that run, sonarqube will analyze all code updated after the last version change, including run-related file changes, in every run.
We run 10-15 builds per day, therefore if we set project version changes with each build, so I’m not sure how much Soanrqube databse is loaded. What is the best strategy if we can bring in all projects at once?
First, I should say there are several options for setting your New Code definition:
Previous version
Specific analysis (an analog to Previous version, but controlled differently)
Number of days (this yields a floating window. The big downside is that if you wait long enough, “new” problems will just “age out”.)
Reference branch (typically this is used so that everything after the branch point is treated as new)
From your question, I assume you’re using Previous version. Whether or not this is your best option depends partly on how often you release to production. The assumption with this option is that you’ll release moderately frequently, and change your sonar.projectVersion string with each release.
It sounds though like that’s maybe not natural to your workflow? (It has its origins in Maven, where changing the version string in the POM file is a natural part of the workflow.) So if you’re releasing regularly, but updating the sonar.projectVersion string is onerous for you, you might want to switch to having your release automation (I’m making some assumptions here) set the analysis of the released version as the specific analysis that’s you’re new code baseline.
To be clear, every file is included in every analysis, regardless. The only real question here is what parts of them are considered “new”.
Regardless of your New Code definition, you do not want to update the sonar.projectVersion string with each build. Doing so sets a version event on each analysis that makes it largely immune from the routine housekeeping routines.
As you stated, regardless of the “new code” setting, Sonarqube will scan every single file. What is the point of defining a “new code” setting? This setting, I assumed, would instruct SonarQube to scan just freshly updated files and will reduce the time required for the sonarqube analysis…
For PR analysis we (try to) limit analysis to only what was changed in the PR. But for other analyses, we analyze everything. Why, to help you Clean as You Code.
The idea is, yes, to focus on the changes in New Code, but new changes can also have impacts in old code.