Hey everyone, been trying to get my head around quality metrics for our junior team. The default SonarQube Quality Gate felt too generic, like we were just aiming for an A grade without it meaning much for *our* actual workflow.
So I finally built a custom one that matches our "definition of done" more closely. It's less about perfection and more about stopping regressions. Here's what I ended up with:
```yaml
# Our custom Quality Gate conditions
- New Code Reliability: Rating worse than A = FAIL
- New Code Security: Rating worse than A = FAIL
- New Code Security Review: Rating worse than A = FAIL
- New Code Duplications: > 3.0% = FAIL
- Coverage on New Code: 0 = FAIL
- New Critical Issues: > 0 = FAIL
```
The key for us was focusing **only on New Code**. We can't fix the whole legacy codebase at once. This gate makes sure our new features don't add big problems or skip tests. The 80% coverage on *new* code is a stretch goal but it's pushing us in the right direction.
Anyone else do something similar? Curious if I'm missing a condition that would be obvious for a team still learning. Also, does this setup make sense for a mostly serverless (Lambda) project?