Must-share information (formatted with Markdown):
- which versions are you using (SonarQube, Scanner, Plugin, and any relevant extension)
- SonarQube Enterprise version 7.9.2 LTS
- MS Build Sonar Scanner version 188.8.131.521, invoked from custom script in TeamCity
- what are you trying to achieve
- I’m trying to understand best practices for the new code period
- what have you tried so far to achieve this
- I have tried changing our new code period in the SonarQube project to 14 days, but there didn’t seem to be a way to set the actual begin and end dates for this period
After spending a lot of time grokking the docs and Googling trying to figure out how to best use the new code period, it became apparent that we may not be setting the version correctly for the “new code” metrics, although it’s not completely clear what the best practices or ideal scenarios for that are.
We are supplying the ‘/version’ parameter for every scan. This value is currently set to the TeamCity build number, which of course increments with every build. This is resetting the “new code” metrics on every scan as expected, including any failed quality gates (despite no code changes), which we do not want.
So, my questions:
What are some guidelines and ideal scenarios for setting the “new code” metrics? We do not version our code, so I would largely expect our new code period to coincide with our 2-week sprints. Would that be reasonable? If so, how would I achieve that?
I understand that I can set the new code period in the SonarQube project manually, e.g. 14 days, but how do I control the begin and end dates for that 14 day period? The 14 day period would be of no use if I can’t control the begin and end dates, as our sprints begin and end on set dates rather than being arbitrary. If that’s not possible, what are other ways to achieve a 14 day period? Or is there another way?
Any help you can offer for the above questions would be greatly appreciated! Also feel free to ask for clarification on anything.