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.
I think your diagnosis is right and this is related to SONAR-8425.
If you’re looking for a workaround, there is the option to create version events on branch analyses, meaning you could flip this to a since previous_version leak (perhaps with an additional initial analysis).
I’ve retroactively added the version event and kept watch of how the new size/new lines to cover metrics evolved with the merges. Even with this it seems to exclude the code that was committed before the event, however the new issues seem to be correctly retained.
Yesterday we merged a quite sizable feature (with a lot of duplication) which has been kept waiting for the external party to be ready (been shelved for more than a release). So now the activity graph shows an increase of around 40K LOC (within the highlighted leak period) yet the ‘new lines’ metric only shows 1.2K and the ‘lines to cover’ metric is even more crazy showing only 71 lines. Now as an indication the biggest module we added shows a metric of 31K Lines of Code. As a note: This merge was not the first analysis after the new period should start.
So I think this case is different from SONAR-8425.
I have the feeling this can relate to SONARSCGIT-24. If it’s the case, you should find a warning in the logs of the analysis which explains that the reference is not found.
Can you please check you have installed version 1.4.1 of the Git plugin?
Unfortunately the problem doesn’t lie within the Git plugin, it seems we’re running 1.4.1 since our upgrade to 7.1. Reading the description of the ticket also seems only partially related. The Branch plugin correctly shows all related files of that change.
I’ve skimmed through the Scanner logs and only spotted an issue about Code Coverage report bytecode not matching for one module (We do some spooky things on that module ).
The problem isn’t within the branch plugin (as far I’m concerned). As MMF-1118 isn’t resolved yet we manually verify that our code meets the Quality Gate coverage/duplication metrics after the code has been merged in the main branch. But for ‘long’ branches (not the long living branches concept from the branch plugin, we use short-lived ones exclusively) of which the development lasted for more than 1 leak period the metrics which were committed before the current leak period don’t seem to get included (maybe backdating is involved here?).
. Will report back once I’m sure if it works as a work around or not.
).