Filipe P.

looks interesting to check, thanks!

I guess we won’t solve it in OSS after all - https://defectdojocommunity.slack.com/archives/C0A494XJ95G/p1772565341169759?thread_ts=1772565263.075929&cid=C0A494XJ95G 😞

asking as I find it perfectly acceptable not to be fork friendly, not meant to be an “hard question”

89 members - I must’ve missed it by so little 😞 🐢

Could there be multiple “baseline tests” (to support multiple tools)? How do they interact with each other in terms of precedence?

IMO that sounds simpler indeed. And it also has the benefit of creating something new rather than using the existing import branch as I suggesting which comes with the issue of retro compatibility with anything using branch However, it’s a similar approach whether it’s branch field in import or a new field in import, it still requires defining how findings are handled when it’s first seen in non-baseline import and then it’s imported into the baseline Or are you suggesting not caring for that? Whenever a finding goes into the baseline import, the other one (and its history) becomes duplicate and maybe an automatic system note is added to the new finding (just to keep some link)? That could work and probably simplify things

which finding is the active (original) one

you mean now or in this setup? I believe now the “latest finding” (the one under analysis) is always the duplicate. In this scenario, I was suggesting that deduplication would consider the “default branch” when doing this. I think it still should keep the oldest as the main one (due to links as I mentioned including the clusters you mention), but it would have to “move it” to the default branch. I haven’t looked into technical details but maybe the original finding could be moved from the test import on the non-default branch to the new test import that is on default branch. And the latest finding the other way around, and marked as duplicate as it would normally be. Anything linked to finding_id would then still be linking to the original finding However this ignores details such as a finding having a date different than the import it belongs to (among other things), not sure if there are expectations on those details

I think main problem with designing it is that Dojo is not strictly pinned to VCS projects (like sonarqube is), however I’d start by thinking along the same lines. sonar knows the branch by passing the branch to the scanner (that uploads it). It knows the default branch because it’s explicitly configured in sonarqube Dojo already takes branch on imports. But it complicates as it can have different tests scanning the same branch, not just different branches… However keeping it simple: