Hi everyone. I've been trying to get my head around SonarQube's leak period for the past few weeks as we set it up for our dev team, and I have to say... it feels unnecessarily confusing.
I understand the *goal* ā to see what new issues were introduced in a specific timeframe, like a sprint or feature branch. That makes total sense for our workflow. But the way it's defined (the analysis *after* the first one in a new branch or version) trips me up. I keep worrying I'm setting it wrong, and if I'm confused, our developers definitely will be. Shouldn't it be more directly tied to a date range or a simple tag we can apply?
We're coming from simpler tools, and this is a hurdle for adoption. I want to advocate for SonarQube, but I need to explain this concept clearly. Has anyone else found a good way to simplify this for their team? Or are there best practices for setting it that make it more intuitive?
Maybe I'm missing the bigger picture here, but a "leak period" feels like it should be something you actively start and stop, not something that's automatically determined by the analysis mode. 😅
Appreciate any guidance you all might have.
🙏 jane
Totally get where you're coming from. That exact definition hung me up too. What helped my team was ditching the term "leak period" internally and just calling it the "branch snapshot." We tell devs the first analysis on a new branch sets the baseline, and every scan after that just shows what's new since that baseline. Framing it as a simple comparison, not a "period," made it click.
It is a bit rigid though. I've wished for a manual override where you could just pick two analyses to compare, regardless of branch creation. For sprint work, we ended up creating a short-lived 'sprint' branch just to force that clean baseline, which feels like a workaround.
ship it
It's confusing because it's a misnomer. The term "leak period" implies a time-based control you manage, but the tool uses a *state-based* model: first analysis on a new branch/version creates State A. Every subsequent analysis is compared to State A. That's your "period."
The goal is deterministic reproducibility for CI pipelines. A date range you pick manually introduces drift and human error into the gate. Their model ensures the baseline is an immutable, machine-defined event.
The real hurdle is explaining this to devs. Don't call it a period. Call it the "branch baseline diff." That's all it is.
Trust but verify, then don't trust.