I am using SonarQube for many years now and was thinking about quality gate configuration lately.
When using pull request analyses, one way (maybe the only way) to enforce the quality of the new code is specifying “Conditions on new code” within a quality gate. That’s nice and the amount of possible conditions that can be set are awesome.
I was wondering why some of the conditions configurable in “overall code” are not available for the “new code”. If someone runs analyses on the main branch and always provides values for e.g. the amount of unit tests, it is unlikely that this differs when running a PR analysis. So the provided data are not processed. Is this correct?
Would it be possible to add those conditions to the “new code” section as well, so that it can be taken into account when scanning pull requests? Am I missing some already available configuration?
Thanks for your response,
I saw there are similar topics but they not really fit my actual suggestion/question.
You’re right that not all ‘overall’ metrics have ‘new’ analogs. There are a number of reasons for that.
The ‘overall’ metrics are a years-long accumulation of things and include metrics that seemed like a good idea a decade ago in the early experimentation around code quality (‘Comment %’ anyone? ). I’ll say that many of them are still there in the list primarily because it hasn’t been worth the effort to clean them out.
On the other hand, “on New Code” metrics are a more recent phenomenon, and we’ve been more cautious about adding to the list. We’ve tried to make sure that every ‘new code’ metric available as a QG condition is relevant to the quality/security of the code. So everything you’ll see there should be both qualitative and actionable.
Regarding specifically the unit test count, that one’s quantitative & so not likely to become available as a QG condition on new code. Also, it’s one of a set of metrics we’ve tried twice in years past to get rid of because we don’t have faith in them as relevant metrics for code quality/security. (And BTW I believe a third attempt is in the planning stages.)
Does that help / make sense?
Thanks for the insights and yes it makes sense. I agree that the amount of unit tests is not that important compared to the quality of the same.
So it’s fine to me that the unit test count is most likely not going to be a “new code” metric.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.