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.
It looks like your analyses fail because they finish out of order. This means that given two commits made closely together, the analysis of the second commit might finish before the first. This puts SonarQube into a bad state because it naturally wants to keep things chronological.
We’ll update this thread as the investigation continues. Naturally, with the holidays, there have been fewer folks around.
Thank you so much for the update. I’m on the opposite schedule and will be away for the next 3-4 weeks. That working theory does seem to align with what I’m seeing: Looked at the last few commits that failed on main and it was in fact where there were 2 closely merged PR’s. On top of that, the last 2 weeks have been silent (because 90%+ of our team was on vacation).
Thanks a lot to all the participants in this thread for helping us identify the underlying behavior and improve our software!
As Colin said, we observe failures when 2 commits are pushed really close to each other and the analyses by Automatic Analysis are completed in the opposite order.
Sadly, this is a known issue that can happen also with CI-based analysis in the same context.
There is no workaround in place at the moment to avoid this ordering problem. The only solution to unblock any pull request impacted by this would be to push a new commit or rebase the branch to trigger a new clean analysis.
The problem has been identified and logged into our internal backlog. It seems there is no quick-win solution, so I can’t commit to a resolution as it will require some prioritization.
