We’ve had 3 instances this week where a Pull Request was opened and the analysis never showed up on the Pull Request. Also when we we went in to the “Pull Requests” section of SonarQube Cloud we could not see the PR listed.
As a test, we recreated the changes on a new branch and that one did show up (same user, same code changes).
We also tried a few empty pushes to the PR because we hoped that maybe a webhook was missed by SonarQube Cloud from Github, but that also didn’t cause the PR to show up.
Because we have SonarQube as a required status check, this blocks the pull request and since additional pushes to the branch aren’t causing it to recognize the PR we have to create a completely new branch or disable this required check.
Is this an ongoing issue? We are seeing something like this on AzureDevOps. The “Prepare” part of the CI pipeline appears to run successfully, but then when it gets to the the “Analyze” step it fails saying it cannot find a PR with the relevant number, and, indeed, when we login to SonarQube we don’t see the PR in that project. This was a pipeline that had worked fine before. Happy to provide additional details. Thanks!
Actually now looking at our full codebase this has actually started happening on multiple pipelines. Happy to provide additional information to help troubleshoot. Thanks!
@samd This thread is exclusively related to an issue involving GitHub. I suggest raising a new thread.
@Michael_C Can you confirm that you’re using Automatic Analysis? I realized this is an assumption I’ve made because some similar reports arrived at the same time.
Thank you for the feedback. Could you confirm when a fix goes out? We saw this happen again on our main branch today at 14:50 UTC for the same repo I mentioned above.
Thanks for the ping. I’ve (re)raised this internally.
Edit to add: It seems that what we did yesterday was only a mitigation. The full fix will be deployed tomorrow. We’ll double-check this case after the deployment.
But our SREs checked the logs this morning, and found no blocked calls since the initial mitigation was put in place. If you’re still experiencing this, the cause is something else.
We are still seeing the issue (at least on on main branch which was the only place I was digging around):
Dec 10, 2024 12:25 UTC
Dec 9, 2024 12:19 UTC
Dec 6, 2024 09:08 UTC
Dec 4, 2024 13:57 UTC
I’ve included a screenshot of the error (I believe that was the Dec 9th error) so you can see it’s on our main branch and that it was cancelled because we didn’t get a status from SonarCloud.
