Reject commit if code doesn't meet quality standard


Can anyone help me in setting up the rejected code check-in if the sonarqube scanner code quality does’t meet the criteria.


Hi @Divin,

Can you give us a bit more details so we can help you?
For example, the version of SonarQube you have installed and the edition you run internally, the SCM you use in your toolchain (Azure DevOps, BitBucket Server, Gitlab, GitHub…)?
Do you use branches? and PR?
Branches and PR analysis are available starting in Developer Edition. You can then block merge based on the status of the PR.


Hello Carine,

Thanks for you quick response, Actually I’m using SonarQube Docker image(sonarqube:latest tag),
Tools: Azure DevOps with Azure repos. we are using Branch and PR. Need to configure the gated check-in for the same.


Let me add up to what @Carine_Bayon told you: We don’t think that blocking a commit that does not meet quality standards is an excellent practice:

  • Committing is also a way to save your work. If you block a commit at the end of a dev working day because he did not fix all his issues, you run the risk of a developer computer crash until he can commit (and it may not be the very next day if he is on a week-end, off, sick… you name it)
  • SonarQube check is one thing but you may want to do several other checks (dependencies etc…). If the dev has to run all those “heterogeneous” checks from his workstation he may be lost, not sure of what to do. Implementing as part of the CI makes it deterministic and not relying on knowledge of each and every developer

Our approach/recommendation is based on the typical modern development pattern which is is that developer commit on a (feature or hotfix) branch, not directly on the main branch. Even if the quality is not satisfactory, the code of the branch will anyway not affect the main branch. You will on the other hand be very strict to block the merge of a PR (a branch) into a main branch if the code of the PR/the branch does not meets quality expectations. Most ALM allow to enforce this policy (see How to block the merge of Pull Requests when SonarQube Quality Gate is failed, with GitHub for instance)

Let me know if that makes sense to you.