I think that feature is something that should be first added to core (SCM) as an extension point. E.g. in general the build stable results (test results, analysis results, etc.) should use that extension point to determine a reference build. Or is this only meaningful for static analysis?

When this extension point is provided, the static analysis plug-in can use that extension point to provide that behavior.

Can you please add some build sequences or examples to describe in more detail your requirements? Currently, in the warnings plug-in a reference build is the last build with results below a threshold. Should this also be done in your use case?

I agree that the issue isn't specific to static analysis.

I think any SCM history which is not linear would benefit from it. The non linear history could be branches, changeset, etc. E.g. if versions B and C are compiled after each other, and they both have A as ancestor, then it is not correct if C is using B as reference build. E.g. if B has introduced a few warnings, than build C would report those warnings as fixed. But they are not fixed because these warning still exist in the separate branch/changeset.

If the threshold is set so that the count for B is above the limit, then relaying on the threshold works correctly. But in the general case it would not give the correct result. Also using the threshold makes it so that a build for version D with ancestor B doesn't report the warnings as fixed.

Also it seems (but I'm highly uncertain so please correct me if I'm wrong), that also unstable builds are considered for the reference build (and only failed ones are excluded). Thus it is not enough to set the status threshold (either new or total) for unstable but one has to set it for failed if one wants to affect the reference build. Also I assume that only the status threshold and not the health threshold effect the reference build.

Ok, I understand. I.e. we need some kind of ancestor of a build. This might be not trivial since not every SCM change will lead to a new build.

Also it seems (but I'm highly uncertain so please correct me if I'm wrong), that also unstable builds are considered for the reference build (and only failed ones are excluded). Thus it is not enough to set the status threshold (either new or total) for unstable but one has to set it for failed if one wants to affect the reference build. Also I assume that only the status threshold and not the health threshold effect the reference build.

Currently, a reference build is obtained from the last build that has a successful (not unstable) warnings result. The warnings result is independent from the overall build result.

Ok, I understand. I.e. we need some kind of ancestor of a build. This might be not trivial since not every SCM change will lead to a new build.

Yes. It is true, in general not every SCM change has to lead to a build. But I think in many important cases it does. Thus supporting only this case would already be very nice. But I would imagine supporting the general case shouldn't be too hard either. If the SCM interface has an API to ask for the ancestor, the plugin could ask for the ancestor of the SCM version of the current build. If no build exist corresponding to that build, the same API could be used to recursively walk back in the history until a version is found which has a corresponding build.

A bit more tricky might be the case that more than one build exist for a certain SCM version. In that case one needs to decide which build should be picked, e.g. the most recent or the most recent successful one.

Is it possible to make any progress on this without the API change in the depending bug? E.g. by making it a git-only feature first and then adding other scm support when the API is added? Having this addressed would be very nice for us.