Quality gates – checks that must pass before some changes can be merged – are a useful way to detect quality problems early. These gates can include any kinds of quality checks, including running test suites or using static analysis tools. The idea is that finding and fixing problems early is much easier (and therefore cheaper) than having to debug changes later in your software development process.
Such quality checks might be part of a developer's personal workflow, but it's best to not count on that. In a pull-request based workflow, it is useful to apply a quality gate before a pull request with some feature can be merged into a shared branch that will then be used as a basis of further development. Such quality checks can then be run by an external CI server, not just on the developer's local computer.
Opinions diverge on whether the CI result should merely be informational or whether any detected problems must be fixed. A team will typically adapt the configuration of the CI system over time so that unnecessary warnings are silenced and relevant problems are treated as hard errors. For milder problems, more intricate metrics might be used for quality gating. For example, a change may not increase the absolute number of warnings, or may not add warnings on lines that were changed. Of course, a list of warnings is much more helpful when it is small and actionable, so often quality gating on static analysis results requires a high quality level in the first place.
In case hard quality gates are not desirable, a milder version is to run any check after the changes have been merged. However, this makes it easy to ignore these problems and let issues pile up. Quality gates require the issue to be fixed before the change can pass the quality gate, so that helps to keep bad code out of the system in the first place.
Using quality gates with static analysis for pull requests is effectively standard in open source projects. Contributors might have a variety of experience levels, so automated checks can help them fix these problems before someone spends time on a code review. In a closed team with lots of experience, that is less important because there will be fewer problems in the first place – but most teams do not have uniformly high experience, so automating some aspects of code reviews through quality gating can save a lot of time.