We’re running into some issues with our current setup with the Leak Period.
Recently a colleague of mine raised some concerns that the amount new_lines metric seemed on the low-side for the change. So I’ve started to monitor my pull requests into our main branch to see if the changes align.
Now I’ve hit into a scenario in which almost all of my lines are excluded from the leak period even though the branch plugin shows 600 LoC modified (which is correct).
So let me sketch the scenario:
We use SQ (7.1 Developer Edition) as one of quality gates before we are allowed to create a branch for the release. This release branch takes about a week before it is merged back into the main branch, thus we opted to use the branch creation date as leak period (so it’s a full date, not relative) and we ensure that an analysis is available for that date so that all new code should be detected. However branches that have changes before and after this date are not detected in full. We provide SonarQube with our Git data.
The example Git Log:
[A] (06/25) | \ | [B] - Code clean up on feature (06/24) | | [C] | - Release start point (06/23) | | | [D] - Feature development (06/22) | / [E] - Feature start point (06/21)
The branch in SonarQube correctly contains commit B and D, however the leak period only reports commit B.
Now let’s see this from two perspectives: Yes this code is created before the leak period and is added after the next leak period started for us. But for us it should be in the leak period as it is the first time that code will ship to production.
Now I got the feeling that it is related to SONAR-8425 but I’m not entirely sure.
What do you think about this?