Before v11.0.0, WarningsNg was able to consider in progress builds for its delta reports. This can mess up delta reports in jobs where concurrent builds are enabled and for long running jobs (3h in our case), it would be a bigger limitation to not have concurrent builds.

In our setup, the jobs can run in parallel but cannot overtake each other at defined checkpoints which prevents mix-up in the reporting.

Note: In this case, no Git is used!

Example of original behaviour:

Build #1 is completed.

Build #2 starts and has #1 as reference build. An early stage creates a recordIssues report. "NEW" issues are correctly related to #1. The build continues for some time.

Build #3 starts before #2 has fully completed. However, it still takes #2 as reference since the previous report is already available!

Example of new behaviour:

Build #1 is a completed.

Build #2 starts with #1 as reference build. It comes to a stage which stores a report with recordIssues with a consistent ID. The build continues for another 2h. For this build #1 is the reference, which is fine - all new-marked issues are related to the changes triggering #2.

New changes are pushed and build #3 is started.

Build #3 starts in parallel to #2 - the reference is still #1 for EVERY report. Now it comes to the early stage of recordIssues which now marks issues as "new" even though they were already found in #2. Now the developer is notified that his changes included in #3 caused issues which actually do not relate to him, but to #2. 

Cause

I think this is related to this change: https://github.com/jenkinsci/warnings-ng-plugin/commit/48b46c855d6d06230f5d1689f387bdbbd2567886#diff-922079efb124d29a7d2ef19d138240f1a640e277aa554cbf2a70ddc7e92d1a9dL41-L56 

To fix this, I think this line should be changed:

https://github.com/jenkinsci/forensics-api-plugin/blob/main/src/main/java/io/jenkins/plugins/forensics/reference/ReferenceRecorder.java#L134

From getLastCompletedBuild() to getLastBuild().

Perhaps introducing a parameter to allow in progress builds would also work. Would be great if the original behaviour could be supported again.

Thanks for all the work!