Hey guys,
We’re pretty in love with SonarCloud, but we found out that the last few weeks (not sure for how long) SonarCloud isn’t cleaning up it’s comments on the pull requests in azure devops after we fixed the issues.
It worked before and we didn’t change the configuration (as far as we know)
Has this become a setting we don’t know about yet? What can be wrong?
Best regards,
Freddy
Hi Freddy,
Have you check that your Personal Access Token for SonarCloud hasn’t expire ?
Mickaël
Hi,
I assumed that the token should still be active, because we still receive the issues on our PRs.
I can see that the token on my SonarCloud account is used. And also the PAT of the account in Azure DevOps is still active.
I’ll try to recreated the PAT token and token in SonarCloud just to be sure and update the outcome here…
Thanks,
Freddy
I created a new PAT just to be sure and I started a new build job to trigger the analyzer.
But SonarCloud doesn’t remove resolved issues like it did before.
SonarCloud still can add new comments for new issues, but when they are resolved in the branch they stay visible on the PR unfortunately.
Best regards,
Freddy
We’ve had this issue since the 15th of April. I reported it in this thread here:
Does this happen for all your pull requests or just some of them? I’m pretty sure with us it is quite sporadic and to when it decides to delete them and when it decides to keep them.
Hi Peter,
I asked my colleagues and they said that SC sometimes (very rarely?) cleans up its comments.
I was not aware of this, thank you for pointing this out.
The majority of comments are left on the PR. Even when it is super obvious that they are fixed in the PR. This all feels like a bug in SC, since it worked flawless before…
For us we prefer the fixed issues to be removed. I’ll post a comment on the other thread with our motivations.
Thanks!
Freddy
Hi,
we have the same issue with our Azure DevOps Server and SonarQube (Developer Edition).
SonarQube writes comments as expected. If I mark a comment in SonarQube as “Won’t fix”, it changes the PR comment to “won’t fix” so adding and editing comments is working fine.
But a problem has been fixed in a Pull Request, the comment is not being deleted.
We have one project where it is working but in all other projects it does not work.
I also renewed the PAT but that does not seem to be the problem.
I think we the problem since updating to version 7.7. Yesterday I updated to version 7.8 but the problem stays.
Best regards,
Daniel
I changed the Logging Level to DEBUG and got this exception in the sonarqube_ce.log:
Maybe this helps:
019.06.27 13:27:06 DEBUG ce[------------][o.g.j.c.ClientExecutorProvidersConfigurator] null
java.lang.reflect.InvocationTargetException: null
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.glassfish.jersey.client.ClientExecutorProvidersConfigurator.lookupManagedScheduledExecutorService(ClientExecutorProvidersConfigurator.java:198)
at org.glassfish.jersey.client.ClientExecutorProvidersConfigurator.init(ClientExecutorProvidersConfigurator.java:148)
at org.glassfish.jersey.client.ClientConfig$State.initRuntime(ClientConfig.java:466)
at org.glassfish.jersey.internal.util.collection.Values$LazyValueImpl.get(Values.java:341)
at org.glassfish.jersey.client.ClientConfig.getRuntime(ClientConfig.java:826)
at org.glassfish.jersey.client.ClientRequest.getConfiguration(ClientRequest.java:285)
at org.glassfish.jersey.client.JerseyInvocation.validateHttpMethodAndEntity(JerseyInvocation.java:143)
at org.glassfish.jersey.client.JerseyInvocation.(JerseyInvocation.java:112)
at org.glassfish.jersey.client.JerseyInvocation.(JerseyInvocation.java:108)
at org.glassfish.jersey.client.JerseyInvocation.(JerseyInvocation.java:99)
at org.glassfish.jersey.client.JerseyInvocation$AsyncInvoker.method(JerseyInvocation.java:691)
at org.glassfish.jersey.client.JerseyInvocation$AsyncInvoker.options(JerseyInvocation.java:646)
at com.microsoft.alm.client.DefaultRestClientHandler.loadLocations(DefaultRestClientHandler.java:64)
at com.microsoft.alm.client.VssRestClientHandlerBase.getLocation(VssRestClientHandlerBase.java:62)
at com.microsoft.alm.client.DefaultRestClientHandler.createTarget(DefaultRestClientHandler.java:123)
at com.microsoft.alm.client.DefaultRestClientHandler.createRequest(DefaultRestClientHandler.java:85)
at com.microsoft.alm.client.VssHttpClientBase.createRequest(VssHttpClientBase.java:200)
at com.microsoft.alm.client.VssHttpClientBase.createRequest(VssHttpClientBase.java:104)
at com.microsoft.alm.teamfoundation.sourcecontrol.webapi.GitHttpClientBase.getRepository(GitHttpClientBase.java:16284)
at com.sonarsource.C.C.B.G.A(Unknown Source)
at com.sonarsource.C.C.B.C.A(Unknown Source)
at com.sonarsource.C.C.B.C.A(Unknown Source)
at java.util.Optional.ifPresent(Optional.java:159)
at com.sonarsource.C.C.B.C.A(Unknown Source)
at com.sonarsource.C.C.Z.A(Unknown Source)
at java.util.Optional.ifPresent(Optional.java:159)
at com.sonarsource.C.C.Z.B(Unknown Source)
at com.sonarsource.C.C.Z.A(Unknown Source)
at org.sonar.ce.async.SynchronousAsyncExecution.addToQueue(SynchronousAsyncExecution.java:27)
at com.sonarsource.C.C.Z.A(Unknown Source)
at java.util.Optional.ifPresent(Optional.java:159)
at com.sonarsource.C.C.Z.finished(Unknown Source)
at org.sonar.ce.task.projectanalysis.api.posttask.PostProjectAnalysisTasksExecutor.executeTask(PostProjectAnalysisTasksExecutor.java:113)
at org.sonar.ce.task.projectanalysis.api.posttask.PostProjectAnalysisTasksExecutor.finished(PostProjectAnalysisTasksExecutor.java:107)
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:207)
at org.sonar.ce.taskprocessor.CeWorkerImpl$ExecuteTask.run(CeWorkerImpl.java:189)
at org.sonar.ce.taskprocessor.CeWorkerImpl.findAndProcessTask(CeWorkerImpl.java:156)
at org.sonar.ce.taskprocessor.CeWorkerImpl$TrackRunningState.get(CeWorkerImpl.java:131)
at org.sonar.ce.taskprocessor.CeWorkerImpl.call(CeWorkerImpl.java:83)
at org.sonar.ce.taskprocessor.CeWorkerImpl.call(CeWorkerImpl.java:51)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: javax.naming.NoInitialContextException: Need to specify class name in environment or system property, or as an applet parameter, or in an application resource file: java.naming.factory.initial
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:662)
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
at javax.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:350)
at javax.naming.InitialContext.lookup(InitialContext.java:417)
… 55 common frames omitted
Hi,
Thanks for the logs, we will have a look.
Mickaël
Hi, is there any news?
This misbehavior is very annoying and we can’t see whether a code smell is still active or not.
Hi,
Do you remember if the undeleted comment was the last issue of the analysis ? So there were no more of them in your PR ?
Thanks.
Mickaël
Yes, I think this is often the case in our scenario.
But we also had scenarios with multiple resolved undeleted comments, not just one comment, but without unresolved issues, I think.
Hi,
We deployed a fix today concerning the last comment of a PR not being deleted.
Could you please run new tests and let us know if there’s anything better in your side ?
Thank you.
Mickaël
Oh, I didn’t read that this is targeting SonarCloud.
We are running SonarQube.
The fix has been done on SonarQube as well, but i don’t have an ETA for the version to come.
We’re having this issue as well, and it seems to happen (almost) all of the time. And with all found issues on the pullrequest, not just the last one.
We’re using sonarqube 7.9.1.
Hi,
SonarQube 8.0 is out now, and should fix this issue for SQ as well.
This seems just bad and amazes me, why would you want to remove the issue comments from PR history? In my opinion they should stay there for tracking and accountability reasons. It looks like now they are deleted by default when fixes have been pushed. I can’t find a way to disable this. Is there any way to persist the PR comments after renewed validation have been run?