which versions are you using (SonarQube, Scanner, Plugin, and any relevant extension)
SonarQube 8.2 Developer + Azure DevOps Server
what are you trying to achieve
Background jobs on Pull requests have stopped working however jobs on branches continue to succeed, error is:
org.sonar.ce.task.projectanalysis.component.VisitException: Visit failed for Component {key=<REDACTED>:<REDACTED>:PULL_REQUEST:633,type=DIRECTORY} located Paramarine:PULL_REQUEST:633(type=PROJECT)
at org.sonar.ce.task.projectanalysis.component.VisitException.rethrowOrWrap(VisitException.java:44)
at org.sonar.ce.task.projectanalysis.component.PathAwareCrawler.visit(PathAwareCrawler.java:52)
at org.sonar.ce.task.projectanalysis.component.PathAwareCrawler.visitChildren(PathAwareCrawler.java:87)
at org.sonar.ce.task.projectanalysis.component.PathAwareCrawler.visitImpl(PathAwareCrawler.java:70)
at org.sonar.ce.task.projectanalysis.component.PathAwareCrawler.visit(PathAwareCrawler.java:50)
at org.sonar.ce.task.projectanalysis.step.PersistComponentsStep.execute(PersistComponentsStep.java:114)
at org.sonar.ce.task.step.ComputationStepExecutor.executeStep(ComputationStepExecutor.java:81)
at org.sonar.ce.task.step.ComputationStepExecutor.executeSteps(ComputationStepExecutor.java:72)
at org.sonar.ce.task.step.ComputationStepExecutor.execute(ComputationStepExecutor.java:59)
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(Executors.java:515)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:835)
Caused by: java.lang.IllegalArgumentException: Component name can't be empty
at com.google.common.base.Preconditions.checkArgument(Preconditions.java:142)
at org.sonar.db.component.ComponentValidator.checkComponentName(ComponentValidator.java:40)
at org.sonar.db.component.ComponentDto.setName(ComponentDto.java:316)
at org.sonar.ce.task.projectanalysis.step.PersistComponentsStep$PersistComponentStepsVisitor.createForDirectory(PersistComponentsStep.java:302)
at org.sonar.ce.task.projectanalysis.step.PersistComponentsStep$PersistComponentStepsVisitor.visitDirectory(PersistComponentsStep.java:211)
at org.sonar.ce.task.projectanalysis.component.PathAwareCrawler.visitNode(PathAwareCrawler.java:99)
at org.sonar.ce.task.projectanalysis.component.PathAwareCrawler.visitImpl(PathAwareCrawler.java:67)
at org.sonar.ce.task.projectanalysis.component.PathAwareCrawler.visit(PathAwareCrawler.java:50)
... 23 common frames omitted
what have you tried so far to achieve this
There has been no change to the system and had been working since updating from 8.1 to 8.2, Have tried cleaning up build agents but hasn’t had any affect.
I have one pull request that doesn’t work despite multiple attempts (probably with ~120 files changed). I have attempted to replicate the issue with a new PR but with only a single line changed the PR is successful. The logs from the scan stage appear not to differ and both report as succeeded. Only the background job fails with the error as above.
Your problem seems to be exactly what I faced. In my project 2-3 PRs failed after upgrading to 8.2. My first impression was that only PRs fail, which were present before the upgrade but not yet completed. They were analysed successfully at least once before. Therefore, I used the workaround to exclude touched files from analysis and undid it once the PR was completed.
But, the issue occurred again with another PR (25 files; 8 adds; 17 edits) that was created after upgrade to 8.2 while many other PRs passed successfully.
Something else I noticed is that when I clicked on the link of the failed PR in the background task overview, SonarQube told me that it the PR was removed or the project deleted. After excluding the touched files and successful analysis, the same link worked.
The extended ce log shows that the step ‘Persist components’ failed.
2020.03.10 09:54:55 INFO ce[AXDDp0b1xWIq-Rjr1n6i][o.s.c.t.s.ComputationStepExecutor] Persist components | status=FAILED | time=0ms
2020.03.10 09:54:55 INFO ce[AXDDp0b1xWIq-Rjr1n6i][o.s.c.t.p.a.p.PostProjectAnalysisTasksExecutor] Webhooks | globalWebhooks=0 | projectWebhooks=0 | status=SUCCESS | time=15ms
2020.03.10 09:54:57 INFO ce[AXDDp0b1xWIq-Rjr1n6i][o.s.c.t.p.a.p.PostProjectAnalysisTasksExecutor] Pull Request decoration | status=SUCCESS | time=1267ms
2020.03.10 09:54:58 ERROR ce[AXDDp0b1xWIq-Rjr1n6i][o.s.c.t.CeWorkerImpl] Failed to execute task AXDDp0b1xWIq-Rjr1n6i
org.sonar.ce.task.projectanalysis.component.VisitException: Visit failed for Component {key=lmda:LMDA:PULL_REQUEST:2341,type=DIRECTORY} located lmda:PULL_REQUEST:2341(type=PROJECT)
at org.sonar.ce.task.projectanalysis.component.VisitException.rethrowOrWrap(VisitException.java:44)
at org.sonar.ce.task.projectanalysis.component.PathAwareCrawler.visit(PathAwareCrawler.java:52)
at org.sonar.ce.task.projectanalysis.component.PathAwareCrawler.visitChildren(PathAwareCrawler.java:87)
When it reoccurred did the pull requests have the common files between the first one to fail or did it appear to be random ? I’m trying to decide the best way to go about this as having to manually exclude the files is going to be very painful.
As we can’t be the only people using Azure Devops with SQ I’m not sure what else we can be doing that means we are the only ones with the issue…
Starting to wish we had stayed on 7.9 it worked and the branching worked far better!
For me it looks kinda random. Can’t tell you exact numbers but 90% of the pull requests complete w/o any issue. Today we completed the last failing pull request. Nevertheless, when this issue occurs again, I will empty the database and hope the issue is then permanently solved. The trade off is the losing of 1.5 years of project history.
Can’t agree more:
Starting to wish we had stayed on 7.9 it worked and the branching worked far better!
Would you be able to advise on the steps to clear the database of all the analysis to remove the issues, ideally while maintaining the custom quality profiles / quality gates ? Would simply deleting the project from the administrator page suffice ?
Sorry I was trying to get use the reply button to ask @dmeneses on how to do it, I wasn’t expecting you to find out for me! But if you do figure it out I would really appreciate you sharing how you’ve done it.
Is there any chance you could run the failing analysis with debug enabled and send me all files of the report (they’re kept when running in debug), which should be in .scannerwork?
I setup a fresh database and changed the sonar config. Unfortunately, by using another database the server id of my sonarqube instance changed, whereby my license key became invalid. Therefore, I changed back to my original database.
How can I delete all payload from the database but keeping the license etc. valid? Does delete the project do the job?
@Daniel.Schiffer further up the message chain I think @dmeneses suggested that deleting the project will delete the data but he didn’t seem to think it would help. See:
@Daniel.Schiffer I’ve been trying (and failing) to share my .scannerwork directory, but have been struggling to find a way to be able to transfer it over to him due to the size. Maybe if you are you able to provide him with the required data it may be quicker then me trying lots of different transfer methods.
Update - I now have examples of a pull request that passed it’s background analysis on the first run but when the developer applied changes to adjust the code for review comments the next analysis and all subsequent attempts fail…
My update: yesterday a pull request failed at first analysis. The code change was only a change of one character within a constant string (‘1’ => ‘01’).
I am not able to narrow down the root cause why some pull requests fail while others not. Therefore, I think more and more about starting the project from scratch with a nice and clean database.