The documentation suggests that the GitHub event provides sufficient details to inform SonarCloud that an analysis is for a pull request, however all of our analyses are showing up as if they were for the main branch, not a pull request.
As far as I can tell, I’m using the default configuration for the SonarCloud GitHub action, per the examples.
Is there any configuration either in my GitHub Action or in my project which would prevent pull request detection on the analyses?
Hi,
It sounds like your SCM metadata isn’t being picked up. Could you provide your analysis log?
The analysis / scanner log is what’s output from the analysis command. Hopefully, the log you provide - redacted as necessary - will include that command as well.
This guide will help you find them.
Thx,
Ann
Hi, Ann! Thank you so much for replying. My redacted analysis log is attached. Note that this is (as much as possible) a “stock” analysis configuration. I had to do an ugly sed expression to get our code coverage xml file picked up and the sources recognized. Also, the intermediate step where I manually set SONAR_PULLREQUEST was recommended by ChatGPT…who later sheepishly admitted that maybe they were hallucinating because the scanner should be able to pick up that it’s looking at a pull request from the GitHub event data.
I also think I may have just figured it out while redacting sonar-project.properties to include that, too. We hardcode the branch name in the properties file, which (I’m guessing) overrides the hints offered by the GitHub event. D’oh!
sonar-project.properties.txt (945 Bytes)
0_SonarCloud Analysis.txt (108.9 KB)
Hi,
sonar.branch.name=main
Yep. That would do it. 
If you assert branch, PR &etc, the integrations aren’t going to override that. (Imagine how frustrating it would be if you wanted to set that manually & couldn’t.)
While I’m looking at your properties, I don’t see a declaration of sonar.sources. So that’s defaulting to .. What I do see is:
sonar.exclusions=**/libraries/**/*,
sonar.coverage.exclusions=**/libraries/**/*,
sonar.cpd.exclusions=**/libraries/**/*,
So first… those trailing commas are weird (but harmless). But if something’s excluded with sonar.exclusions there’s no need to further exclude it for coverage & duplications (cpd). Those are subsets. It’s already not part of the analysis at all, so there’s no way it could be considered for coverage & duplications.
sonar.inclusions=**/*.js, **/*.tf, **/*.py, **/*.jsx
It’s a fairly rare circumstance that you actually need both inclusions and exclusions together. Are there other file types that you just really don’t want included in the analysis? And if so, why not add them to the exclusions?
Really, you’re better off trying to set a good sonar.sources value. And even better off relying on the docs rather than ChatGPT 
And finally, there’s this:
sonar.test.inclusions=**/__tests__/**/test_*.*, **/test-helpers/**/*, **/tests/test_*.py
You’re trying to specify which subset of files described by sonar.tests to actually include as test files. But… there’s no sonar.tests definition. sonar.sources defaults to . because you won’t get very far in analysis if you don’t tell us where the source files are, so we kindly provide a sane default. But there’s no default for sonar.tests, so there’s nothing to subset from.
HTH,
Ann
Thanks for the review on our properties file. Totally own that we cribbed it from our “neighbor” and never looked deeply beyond that, since it more or less seemed to be working.
Ran into an odd twist. Removing the hardcode allowed it to recognize it wanted a pull request again. Yay! Then it still failed, because I had removed the SonarCloud app integration, since I thought it was just giving me “doubles” of CI and automatic analysis .
Even though we pass the action a GITHUB_TOKEN with pull request write permissions, it seems like the only way the analyzer could obtain the pull request was by using the SCM project binding at the SonarCloud project level through the SonarCloud app integration. Is that expected behavior?
I added GitHub app integration back in and now our pull requests are working again (both the GitHub App and the CI analysis).
Hi,
Yes. PR decoration comes from the server, and it’s done with the perms bound on the server side. Analysis submits an analysis report bundle to the server, which queues it and then processes it in turn. CI-side analysis is long-complete (in computer terms) by the time PR decoration happens.
HTH,
Ann
Okie! I’ll turn off quality gate checking in my CI run, then. That will always “succeed” so long as analysis was run; the quality gate check can come to us from the server-side.
It seemed like we were having two scans done per pull-request: one from CI and one from the SonarCloud GitHub app. I didn’t understand that it was “two step”: one to run the scan, and one to receive the quality gate results.
Hi,
It is a discrete action to receive the Quality Gate results from the server. Your sonar.qualitygate.wait parameter puts your pipeline in a holding pattern until the analysis report is popped from the queue, processed & stored. At that point your QG results are available to be reflected in your pipeline and/or decorated into your PR.
Ann