I am using the automatic github integration with sonarqube. It used to be that Sonarqube would annotate pull requests with issues on changed lines of code - allowing us to use sonarqube as a blocking gate to prevent new issues from being introduced to our repository.
It seems something changed this week, because our pull requests are suddenly being annotated with all issues in any file touched, not just on the new code introduced in the file. This introduces a lot of noise to our pull requests and makes them harder to review. The integration is also reporting the whole PR as failed even if none of the issues were introduced in the specific PR. Ideally, we’d like to be able to keep PRs small and follow-up on these unrelated issues with separate PRs, especially since some issues may be non-trivial fixes.
Other context:
* The project is hosted on sonarcloud
* Our repository is configured to treat new code as any code introduced within the last 90 days
There’s something I’d like to clarify: do these “unrelated” issues appear only on the GitHub PR decoration (meaning, in the GitHub side)? Or do they also appear on the PR in SonarQube Cloud side? If you go to your project in SonarQube Cloud and to your PR, do you see these issues there too?
A few other ideas to start troubleshooting: does the overview page in SonarQube Cloud for this particular PR show any analysis wanings? If you’re running CI-based analysis (runs on your GitHub actions), do you see any warnings in the logs?
Yes, the issues show up on both the github side as decorators and on the sonarqube side. Sonarqube reports back to github that the PR is failing the quality gate for changes that were not made in the PR.
If by CI-based analysis, you mean initiating the scan via our own Github action, we are not using that. This repository was set up with Automatic Analysis.
The project’s New Code configuration is set up to be based on number of days, currently configured to 90 days. Though, even accounting for that, some of the lines its flagging are beyond 90 days old.
Hey @jlaminate, okay, I see, if you’re using automatic analysis then you can’t check the logs yourself… Could you go to project’s Administration > Background task and find the Project Analysis task corresponding to this PR? You might need to filter by date to match the date in which the latest push happened in the PR, and if you’re not sure, you can click on the 3 dots on the right > show SonarScanner Context and search for sonar.pullrequest.key, which will be set to the PR key on GitHub.
Once you have located the analysis task, could you let me know what’s the ID? This is just so that I can check the logs and see if there are any obvious sings of anything going wrong.
Hey @jlaminate could I ask you to check something? Do you have any recent analyses/have you every analyzed both the PR branch and the develop branch? I mean, a branch analysis on those branches, not a PR analysis. If so, could you check if develop also shows these “unrelated” issues that are being found on the PR? Could you check if there’s anything anomalous in develop, like for example not any issues found at all in the branch, or way less than expected?
Looking at the branch analysis for the master branch, it does look like these “unrelated” issues aren’t flagged in our master branch for some reason. I checked one of the issues being flagged in a PR and compared it to the analysis of the same file in our master branch and there was nothing flagged in that file. That’s not to say there were no issues flagged in our master branch- but for some reason the file I looked at had nothing.
Hey @jlaminate, could you share the name of this file, together with the date when master was last analyzed?
I think this issue looks similar to something I’ve been seeing recently, and there might be 2 potential bugs at play:
There is an incomplete analysis of your master branch (might be project-specific).
The lack of these issues on the master branch is causing them to surface in the PR when the issues are on untouched code (might be generalized in such edge cases).
It’s appeared multiple times, but app/admin/organization.rb would be one that I’ve noticed it recently. Last scan on master would be today. There was a ~2 week period where the scan on master was failing due to LOC limitation, but I resolved that and the issue is still appearing on new PRs. The issues are also issues that would have appeared before that scan outage.
Hey @jlaminate, and just to confirm: after resolving the issue with the failing scans on master, have you re-run the PR analysis? If not, could you try that?
Another user is having a similar issue and after fixing the analysis of the PR’s target branch, the issues on the PR went away (they were reported on the target branch instead). I’d like to confirm if it will work the same way for you.
Thanks for confirming @jlaminate, in that case yours might be a different problem. Let’s wait for the devs to chime in, they might be able to check if anything looks odd in your project.
