Hi Marvin, welcome to the SonarSource Community!
What you’re looking for is generally accomplished via customization to your Quality Gate criteria (click in the Quality Gates top-level menu and configure the one used for your project).
However, before we dive into how to do that, I invite you to observe that code smells are already enforced via the Maintainability Rating which is enforced as part of the default “Sonar way” Quality Gate. Unlike bugs or vulnerabilities, where a single issue might cause the rating to fall below A and fail the Quality Gate, the Maintainability Rating is about code smell density. There need to be a strong enough density of code smell issues relative to the estimated effort to rewrite the affected code for the rating to fall. This reflects our general opinion that individual code smells don’t generally warrant failing a gate; what you’re after is generally minimizing your technical debt which you may do by voluntarily fixing reported code smells even though the gate didn’t fail, or taking the problem more seriously if enough smells have accumulated for the maintainability rating to finally fall. This approach will make the most sense if you have a well-configured New Code period since then the density of code smells relative to the new code is likely to be much higher and cause the rating to drop (and thus a gate failure).
Bottom line: failing a build over a single code smell is probably a very draconian measure. I’d like you to consider if it’s what you really want before I tell you how.