-
SonarQube Enterprise 9.7.1 and Sonar-Scanner 4.7.0.2747-linux
-
We are deploying SQ through k8s kustomize (via translation from helm)
-
We would like to be able to get a fix for this bug.
-
In order to not block developers we have shifted to “Only build during Pull Requests”
In our CI environment, we have the Sonar Code Analysis GH App results deciding whether or not the branch passes or fails SQ.
We are facing a bug where occasionally the GH App will hang indefinitely and never report the results of the Pull Request.
Sonar-Scanner will tell us “Execution Success” but the PR results are never to be found within SQ server. However, the branch that the PR is based off of will still be present within SQ.
Evidence of the above:
17:56:12.884 DEBUG: Upload report
17:56:12.944 DEBUG: POST 200 *******************************/api/ce/submit?projectKey=[redacted]&characteristic=pullRequest%3D6353 | time=60ms
17:56:12.946 INFO: Analysis report uploaded in 62ms
17:56:12.947 DEBUG: Report metadata written to /tmp/sq/.scannerwork/report-task.txt
17:56:12.947 INFO: ANALYSIS SUCCESSFUL, you can find the results at: *******************************/dashboard?id=[redacted]&pullRequest=6353
17:56:12.947 INFO: Note that you will be able to access the updated dashboard once the server has processed the submitted analysis report
17:56:12.947 INFO: More about the report processing at *******************************/api/ce/task?id=AYczqbX1YZwQt8Or-R7j
Upon navigating to https://[sonarqube_url]/dashboard?id=[redacted]&pullRequest=6353 we see the following:
However, we can confirm that the branch is present within SQ.
We believe the flow to trigger the bug is as follows:
- Developer creates a branch locally
- Developer pushes this branch to remote
- CI kicks off sonar-scanner and scans the branch
- Sonar-Scanner sends the results to SQ server
- SQ begins processing the results
- Developer creates Pull Request
- CI kicks off sonar-scanner and scans the branch again
- Sonar-Scanner sends the results to SQ server again
- While SQ is still processing the results, the PR analysis comes in
- SQ begins processing PR analysis
- At some point between 9 and 10, the branch analysis finishes and the PR analysis is dropped
- SQ reports the status of the branch, but the PR status is non-existent
Inside DD, we have the following logs which we believe prove the above hypothesis:
Mar 30 10:56:12.889 POST 200 /api/ce/submit?projectKey=[project_key]&characteristic=pullRequest%3D6353
Mar 30 10:56:23.000 Purge db | status=SUCCESS | time=576ms thread-id: AYczqNS5YZwQt8Or-R7b
Index analysis | status=SUCCESS | time=77ms thread-id: AYczqNS5YZwQt8Or-R7b
Update need issue sync for branch | status=SUCCESS | time=8ms ""
Publishing taint vulnerabilities events | status=SUCCESS | time=2ms ""
Send issue notifications | newIssuesNotifs=0 | newIssuesDeliveries=0 | myNewIssuesNotifs=0 | myNewIssuesDeliveries=0 | changesNotifs=0 | changesDeliveries=0 | status=SUCCESS | time=8ms ""
Publish task results | status=SUCCESS | time=0ms ""
Trigger refresh of Portfolios and Applications | refreshesAPP=0 | refreshesVW=0 | status=SUCCESS | time=28ms ""
Webhooks | globalWebhooks=0 | projectWebhooks=0 | status=SUCCESS | time=11ms ""
Pull Request decoration | status=SUCCESS | time=0ms ""
Persist sources | status=SUCCESS | time=12872ms ""
Persist cross project duplications | status=SUCCESS | time=0ms ""
Enable analysis | status=SUCCESS | time=13ms ""
Update last usage date of quality profiles | status=SUCCESS | time=30ms ""
Mar 30 10:56:23.949: {
bytes_received
8274
bytes_sent
25397
downstream_local_address
140.82.113.6:443
downstream_remote_address
10.146.70.118:56360
duration
121796
http {
status_code
0
}
requested_server_name
api.github.com
response_code
0
response_flags
-
start_time
2023-03-30T17:56:23.949Z
upstream_cluster
outbound|443||api.github.com
upstream_host
140.82.113.5:443
upstream_local_address
10.146.70.118:56838
}
Mar 30 10:56:24.220: {
bytes_received
1855
bytes_sent
14171
downstream_local_address
140.82.113.6:443
downstream_remote_address
10.146.70.118:56368
duration
10201
http {
status_code
0
}
requested_server_name
api.github.com
response_code
0
response_flags
-
start_time
2023-03-30T17:56:24.220Z
upstream_cluster
outbound|443||api.github.com
upstream_host
140.82.113.5:443
upstream_local_address
10.146.70.118:56842
}
Mar 30 10:56:25.000: Report branch Quality Gate status to devops platforms | status=SUCCESS | time=1828ms ""
Mar 30 10:56:25.000: Executed task | project=[project] | type=REPORT | branch=[branch] | branchType=BRANCH | id=AYczqNS5YZwQt8Or-R7b | submitter=github | status=SUCCESS | time=70133ms
Mar 30 10:57:40.521: {
bytes_received
1409
bytes_sent
4709
downstream_local_address
140.82.114.6:443
downstream_remote_address
10.146.70.118:41016
duration
120054
http {
status_code
0
}
requested_server_name
api.github.com
response_code
0
response_flags
-
start_time
2023-03-30T17:57:40.521Z
upstream_cluster
outbound|443||api.github.com
upstream_host
140.82.114.6:443
upstream_local_address
10.146.70.118:41026
}
All the quotations above indicate that the thread-id is the same. As you can see above, the PR ID (id=AYczqbX1YZwQt8Or-R7j) is never reported, which causes the GH App to never get a valid decoration which causes a hang.
Any help with resolving this issue would be greatly appreciated! Our current work-around is to disable builds on branches, but there are some cases where this is required and it would be helpful if we could get some guidance.
Thank you very much in advance!