I’m currently evaluating SonarQube and I’m having trouble with GitLab MR decorations. Setup:
SonarQube Developer (through official Docker container) Version 8.3.1 (build 34397)
Self-hosted GitLab
GitLab MR decorations work fine if the quality gate passes. However, when I add some quality problems to a MR and push those changes (so that the quality gate fails), I get the following error in the SonarQube log:
2020.07.01 13:37:54 ERROR ce[AXMKmDPpYxT2WQianMqX][c.s.C.D.D.B] An exception was thrown during Merge Request decoration : Remote host terminated the handshake
2020.07.01 13:37:54 ERROR ce[AXMKmDPpYxT2WQianMqX][o.s.c.t.p.a.p.PostProjectAnalysisTasksExecutor] Execution of task class com.sonarsource.C.D.c failed
java.lang.IllegalStateException: Remote host terminated the handshake
at com.sonarsource.C.D.D.F.A(Unknown Source)
at com.sonarsource.C.D.D.B.A(Unknown Source)
at com.sonarsource.C.D.c.A(Unknown Source)
at java.base/java.util.Optional.ifPresent(Unknown Source)
at com.sonarsource.C.D.c.B(Unknown Source)
at com.sonarsource.C.D.c.A(Unknown Source)
at org.sonar.ce.async.SynchronousAsyncExecution.addToQueue(SynchronousAsyncExecution.java:27)
at com.sonarsource.C.D.c.A(Unknown Source)
at java.base/java.util.Optional.ifPresent(Unknown Source)
at com.sonarsource.C.D.c.finished(Unknown Source)
at org.sonar.ce.task.projectanalysis.api.posttask.PostProjectAnalysisTasksExecutor.executeTask(PostProjectAnalysisTasksExecutor.java:118)
at org.sonar.ce.task.projectanalysis.api.posttask.PostProjectAnalysisTasksExecutor.finished(PostProjectAnalysisTasksExecutor.java:109)
at org.sonar.ce.task.step.ComputationStepExecutor.executeListener(ComputationStepExecutor.java:91)
at org.sonar.ce.task.step.ComputationStepExecutor.execute(ComputationStepExecutor.java:63)
at org.sonar.ce.task.projectanalysis.taskprocessor.ReportTaskProcessor.process(ReportTaskProcessor.java:81)
at org.sonar.ce.taskprocessor.CeWorkerImpl$ExecuteTask.executeTask(CeWorkerImpl.java:209)
at org.sonar.ce.taskprocessor.CeWorkerImpl$ExecuteTask.run(CeWorkerImpl.java:191)
at org.sonar.ce.taskprocessor.CeWorkerImpl.findAndProcessTask(CeWorkerImpl.java:158)
at org.sonar.ce.taskprocessor.CeWorkerImpl$TrackRunningState.get(CeWorkerImpl.java:133)
at org.sonar.ce.taskprocessor.CeWorkerImpl.call(CeWorkerImpl.java:85)
at org.sonar.ce.taskprocessor.CeWorkerImpl.call(CeWorkerImpl.java:53)
at com.google.common.util.concurrent.TrustedListenableFutureTask$TrustedFutureInterruptibleTask.runInterruptibly(TrustedListenableFutureTask.java:125)
at com.google.common.util.concurrent.InterruptibleTask.run(InterruptibleTask.java:69)
at com.google.common.util.concurrent.TrustedListenableFutureTask.run(TrustedListenableFutureTask.java:78)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.base/java.lang.Thread.run(Unknown Source)
Caused by: javax.net.ssl.SSLHandshakeException: Remote host terminated the handshake
at java.base/sun.security.ssl.SSLSocketImpl.handleEOF(Unknown Source)
at java.base/sun.security.ssl.SSLSocketImpl.decode(Unknown Source)
at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(Unknown Source)
at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
at okhttp3.internal.connection.RealConnection.connectTls(RealConnection.java:336)
at okhttp3.internal.connection.RealConnection.establishProtocol(RealConnection.java:300)
at okhttp3.internal.connection.RealConnection.connect(RealConnection.java:185)
at okhttp3.internal.connection.ExchangeFinder.findConnection(ExchangeFinder.java:224)
at okhttp3.internal.connection.ExchangeFinder.findHealthyConnection(ExchangeFinder.java:108)
at okhttp3.internal.connection.ExchangeFinder.find(ExchangeFinder.java:88)
at okhttp3.internal.connection.Transmitter.newExchange(Transmitter.java:169)
at okhttp3.internal.connection.ConnectInterceptor.intercept(ConnectInterceptor.java:41)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:142)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:117)
at okhttp3.internal.cache.CacheInterceptor.intercept(CacheInterceptor.java:94)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:142)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:117)
at okhttp3.internal.http.BridgeInterceptor.intercept(BridgeInterceptor.java:93)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:142)
at okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(RetryAndFollowUpInterceptor.java:88)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:142)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:117)
at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.java:229)
at okhttp3.RealCall.execute(RealCall.java:81)
... 30 common frames omitted
Caused by: java.io.EOFException: SSL peer shut down incorrectly
at java.base/sun.security.ssl.SSLSocketInputRecord.decode(Unknown Source)
at java.base/sun.security.ssl.SSLTransport.decode(Unknown Source)
... 53 common frames omitted
2020.07.01 13:37:54 INFO ce[AXMKmDPpYxT2WQianMqX][o.s.c.t.p.a.p.PostProjectAnalysisTasksExecutor] Pull Request decoration | status=FAILED | time=59187ms
At first I suspected that maybe the GitLab server rejects TLSv1.0 requests, but that is not the case (verified with openssl s_client -connect git.example.com:443 -tls1).
Any pointers how to debug this would be welcome. I’m a bit confused because decoration seems to work for merge requests where the quality gate passes… Maybe it’s a bug?
From another post you made on this forum, I suspect you are setting sonar.qualitygate.wait=true, in order to fail the GitLab build if the quality gate does not pass. Is this correct?
If that is the case, the scanner running in the Gitlab CI job will need to poll your SonarQube compute engine server until the quality gate status is computed and returned. If your server does not manage to compute this within a reasonable time window, the scanner will cut the polling. There is a default timeout for this, that you can override with the scanner parameter sonar.qualitygate.timeout . Try first with 300ms and gradually increase it if it does not work.
Ah, no worries… I’m not accustomed to my name being common
I tried your suggestion and increased the waiting timeout from the default of 300s to 600s. However, it did not help. But while composing the reply with all the logs, I think I found the problem. I set up the project with a custom project ID (say my-project). However, GitLab CI sends the reports to a SonarQube project with a different ID (say com.example:MyProject). In the SonarQube web UI I can also see that a second project with the longer ID was created.
I fixed this by setting the -Dsonar.projectKey= parameter when invoking mvn verify sonar:sonar. Now the CI job fails immediately after analysis with a quality gate failure. According to the Docker logs, pull request decoration was successful:
I can also see the pull request under /project/branches?id=my-project
However, no comment was created in the merge request thread (SonarQube creates a summary comment with a quality rating when the quality gate passes). Is this normal?
In order for the Quality Gate to fail on the GitLab side when the Quality Gate fails on the SonarQube side, the scanner needs to wait for the SonarQube Quality Gate status. To enable this, set the sonar.qualitygate.wait=true parameter in the .gitlab-ci.yml file.
Have you added the parameter sonar.qualitygate.wait=true to your pipeline? If yes, then, to debug this, the full gitlab job log would help. Also, the pipeline configuration file for gitlab (.yml).
I would need the logs of the build, which I cannot open.
Also, just checking, what is the version of your self-hosted GitLab CI? The minimum supported is version 11.7.
Oh wow, this is a bit embarassing. It seems that when I deleted and re-created the project while testing, I did not re-enable MR decoration on the project level again. They were still enabled on the global level, but not on the project level.
I’ll do some more testing and will confirm whether everything is now fully working as expected. Two suggestions already how reporting could be improved for new users:
The warning above could contain a link to the proper settings page (I already saw that warning before, but then accidentally landed on the global configuration page where decorations were enabled and everything seemed right)
If it’s possible to detect, the backend logs could contain a warning instead of Pull Request decoration | status=SUCCESS
It seems that properly setting the project ID and configuring the PR decoration in the project settings seemed to work. Thank you for your assistance! This issue can be considered fixed.