Hello,
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.
Olivier