Long Lived Branch Analysis/Issue Synchronization

Have two projects in SonarQube Enterprise Edition, Version 7.9.5

Both projects have master and release branches configured as long Lived Branches.
Project A has master (LLB) scanned several months ago and identified 5 vulnerabilities in the project. Release Branch 521 (LLB) got scanned today and identified the same 5 vulnerabilities as new ones , marking them as issues created 4 hours ago
Project B has master (LLB) scanned several months ago and identified vulnerabilities in the project. Release Branch 521 (LLB) got scanned today and identified the same vulnerabilities but they got synced with Master and were aged appropriately as 6 months old issues, with a message saying “The issue has been copied from branch ‘master’ to branch Release-521” .
Scanner parameters were the same for both projects, trying to understand why the syncing between branches happend for one project but not the other

Here is what i found in the doc, so seems like the issues for project A should have been synced?

Issue Creation and Synchronization

During the first analysis, issues (type, severity, status, assignee, change log, comments) are synchronized with the Main Branch. In each synchronized issue, a comment is added to the change log of the issue on the branch: “The issue has been copied from branch ‘master’ to branch yyy”.

At each subsequent analysis of the branch, any new issue that comes from a pull request automatically inherits the attributes (type, severity, …) the issue had in the pull request. A comment is added to the change log of the issue on the branch: “The issue has been merged from ‘xxx’ into ‘yyy’”

Thank you
Elena

Hi Elena,

Do you happen to still have access to the analysis log (ideally including the analysis command itself) of A/Release Branch 521? Also, to be super-clear & ask the dumb questions, A/Release Branch 521 does show up as a branch under Project A?

Regarding issue synchronization, you’ll notice that what’s not in that list from the docs: creation date. And on a related topic, where there comments or changes to metadata in those 5 issues in the main branch?

 
Ann

Thank you for your reply,

I have requested analysis logs from the developers that scanned the code, hoping to get them by tomorrow.
Project A, Release-521 shows up as a branch under Project A. When i check under resolution for those issues(main branch) for the same 5 violations i see them marked as 5 unresolved and 5 Fixed. Project B only has unresolved issues. I am not sure how the same issues could be both marked closed and opened, now that i see that its even more confusing .

Thanks again for your help!

Hi,

So I think the root of this is indeed in those Project A Closed/Fixed issues. From the changelog (thanks for including that!!!) I’m guessing the file move detection glitched/failed. If so, that would explain why the issue was closed on the old file/path and opened fresh on the new path. Do the Open versions of the issues share approximately the same date with the closed issues in their changelogs?

And to ask the dumb question, the files for the issues in A/Release Branch 521 do share an exact path with the Open issues in Project A?

 
Ann

1 Like

Hi Ann, after you asked that question i compared the path and that was the issue. There was no glitch or failure, the difference between Project A and Project B was that project B files remained in the same folders while project A had a version subfolder that makes it look like the files and issues are brand new and unrelated to previously resolved. So thank you so much for asking that question and helping me find the root cause for this!

1 Like