Hi,
Thanks. I’m not sure where to go from here. I’ve flagged this for more expert eyes.
Ann
Hi
Do you know if someone else had a look at this ?
Hi,
Sorry, I don’t have any word.
Ann
Once more sorry for the delay 
Could you describe the exact flow with example dates, so I can understand the problem better?
E.g.
- Analysis 1 at time X, prevVersion=XXX
- X lines not recognized as new code, originally committed at time X-5
2. Analysis 2 at time X+2days, prevVersion=XXX
- X lines not recognized as new code, originally committed at time X-3
Thanks for looking at this.
I think what you are requesting is what I did earlier.
If you see my post: All New code not detected when using Previous version - #5 by Kennet
I did a more simple test that showed the issue with very few commits compared to the original post.
The picture shows the commits and I added the SonarQube versions used while building in the right side of the picture.
The commits that has a SonarQube version is the commits that was build. There are two build of main and two builds of the branch that was merged to main in the last commit “Merged PR 36737”.
In the post All New code not detected when using Previous version - #7 by Kennet
You can see two screen shots the one from DevOps and one from SonarQube. They show that commit with hash: 839f0fa2 is not showing as new code in SonarQube.
So to put it in you format.
- Analysis 1 at “6 Nov 2025” on main.
- I do not know what new code was missing in this build. But next build shows missing code.
- Analysis 2 at “18 Mar 2026” on main.
- There is 3 Lines missing in new code detected by SonarQube. ( Line 96, 97 and 98 )
I do not understand why you would like to have two builds after each other with “lines not recognized as new code”.
/Kennet
Thanks @Kennet !
And when were the missing lines committed?
@Kennet I need one more thing - what was the previous version setting on both analysis on main?
This is how the pipeline looked then that two analysis on main was preformed.
The line in read was removed as suggested by Ann before the runs on the 18 Mar 2026.
The change only affects builds on branches. So when the two builds of the branch (not main) was made the version was 1.0 as you can also see in the screenshot.
But I do not think this makes a difference for the builds on main.
Hi
Did I understand your question about “previous version setting” correctly or is there some other setting you are thinking of ?
Hi @Kennet
You understood correctly 
I did some digging, and the algorithm we use to detect the new code analyzing a branch that doesn’t have a reference branch set, and isn’t a PR, depends on the dates provided by SCM.
Basically, we check if a line has been changed after the date of the analysis set as the previous version.
What’s the date returned by blame for the missing lines? It looks like for some reason it falls before the previous version date.
Anita
Hi
Is it possible to see what the “date of the analysis set as the previous version” is ?
Hello @Kennet,
To get this date you can use:
GET api/measures/component?component=<key>&metricKeys=ncloc&additionalFields=period
Response will include a “period” object:
"period": {
"mode": "previous_version",
"date": "2026-01-01T01:00:00+0000"
}