For Short-lived branches (SLBs) and PRs, the Leak/New Code period currently encompasses every change made after the first analysis.
As a consequence:
- If the PR is rebased on master, in subsequent analyses all the lines modified in master after the first analysis of the PR will wrongly be considered as new in the PR.
- Lines modified in the P/R after the branch was created, but before the first analysis won't be considered new.
It's tempting to try fixing this by simply moving the start of the New Code period back in time by some arbitrary amount, but it's impossible to find a single date as a threshold that will work correctly. We always risk missing changes in the P/R before that date, and moving the start date backward doesn't fix picking up changes in master after that date.
The most accurate way to know which lines were changed is to get that information straight from the SCM, obtained from the scanner side.
- Extend the Scanner SCM API to give the ability collect the additional per-line info we need.
- Update Git and SVN SCM plugins to use the updated API (Other SCM engines handled later)
- Scanner adds new line info in the analysis report.
- CE stores the data.
- Web services publish the data
- Front end uses the data instead of computing new lines based on line date and leak period start.
If the expanded data set isn't available (either the SCM plugin hasn't been updated yet, or the user hasn't done the upgrade) we will retain the current behavior but make the calculation on the server side rather than in the front end.