Feature: silence issue for PR only

Get help SonarCloud
#1

We have many strict rules for our code analysis such as requiring minimum code coverage, and of course all the default critical and blockers from Sonar Way.

One problem we have is that if there is an urgent PR for a temporary fix then our merges are blocked by one or more issues. This is even more of a problem is we refactor a method name for example as it could touch dozen of files and the code coverage requirement could be flagged on them.

Today the only option for us to let the PR go through is to silence these blocking issues, and they get marked as either false positive or as minor. This mean that they are now out of focus forever.

A much better approach for long term management of the issues would be to allow the issue to be acknowledged but allowed/silenced for the current PR. This would allow for the issues to remain in the critical list of issues that should be addressed so that they can be properly fixed at a later date.

We still want to have these issues blocking a PR at least initially to force developers to review them.

#2

Does your git tool not allow force merging PR’s?

What we do in these cases is ask a team lead to review that the quick fix is necessary and that it’s allowed to force through the PR with a failed quality gate. The benefit is that the PR also logs that this happened so it’s traceable. We use azure devops for this.

#3

@Rouke.Broersma.IS Yes, we use GitHun.com and have ‘admin’ users that can force merge. But this is a rather cumbersome enforcement and signals the developers that we do not trust them. We have a model of Freedom and Responsibility were we still require a code review to happen but do want to avoid bureaucratic bottlenecks.

Since Sonar allows anyone to change the severity of an issue or mark it as false positive, a file lacking line or branch coverage is simply marked as such: low severity or false positive. There are bugs in Sonar such as requiring code coverage on empty __init__.py files. So we still want our developers to be allowed to use their best judgment, but not encourage them to silence genuine issues permanently.

So overall having the ability to ACK and temporarily unblock a blocking issue would really help.

For context we are not talking about quality gates per say, we want ti use them to force or devs to review things, but not necessarily always address them on the spot.

#4

In my opinion if the fix is so urgent that standards can be let down, that is when a team lead should be available to make that decision and that team lead can push through the PR and accept the lacking standards. If that doesn’t work for your org I can understand but it sounds to me like you simply should allow more people the permission to push through a merge.

And by team lead I mean a lead or senior developer in the team and not a manager.

#5

Unfortunately GitHub.com does not allow for such granularity. We would have to make such leads admins on the repo, which is not desirable for compliance reasons. It would also allow to accidentally bypass other enforcements that we need to keep strict such as requiring signed commits.