- ALM used (GitHub)
- Languages of the repository (Python)
This sure looks like duplicated code to me. What about it makes you think it’s a false-positive?
Only README.md file was touched in that particular PR.
The PR got CI failed due to files unrelated to the current changes.
Thanks. That’s a weird one – especically since (if I’m not mistaken) you’re using Automatic Analysis.
I’ll flag this for attention.
Yes, especially frustrating cause I can’t find any logs that might clue me in to what might be wrong!
I have seen similar fails before, so I can dig out the relevant PRs there, but some of them are old enough that the analysis details are gone.
Any updates on this?
Sorry for a late answer.
Thank you for reporting this issue. It’s possible that we have a bug in one of our python analyzers. We’re currently investigating the issue to find the root cause. I will keep you posted as soon as we have an update.
We found out that this issue is happening only on what we call external PRs - in this case the PR is from a forked repository to your original repository - currently we have a very limited support of this kind of PRs in Automatic Analysis. It’s one of our objectives to improve this in the close future.
I see that the PR of this topic has been already merged, and you are able to continue using Automatic Analysis.
Thank you for pointing out this issue, we included it in our backlog and it will tackled and fixed on one of out next improvement sprints.
This limitation essentially renders SonarCloud useless for open source projects then, as many (if not most) contributions are external.
Depending on the project, most if not all “internal” PRs may also be coming from each individual member’s personal fork.
I am able to force merges even tho checks fail (not ideal, but required when checks fail for random unrelated reasons).
This one is also arguable a false positive, as the cognitive complexity didn’t cross the threshold in this PR (tho it increased by one), and the two other smells are from unrelated code.