The scan fails if the source code of a git branch is checked out in a worktree. In that case “.git” is a file containing the location of the actual “.git” directory for that worktree.
Scanner log error of Jenkins job: ERROR: Error during SonarQube Scanner execution ERROR: Unable to open Git repository ERROR: Caused by: repository not found: F:\Sources\repositories\tools.git\worktrees\worktree-name
Content of “F:\Sources\worktrees\worktree-name.git” file inside the worktree directory:
The scanner has to resolve the content of the “.git” file to the actual “.git” directory.
We want to analyze multiple branches on the same machine, with worktrees we can checkout multiple branches at the same time from the same repository.
The workaround of having multiple clones of the same Git repository is not an option because our source code is too large.
I took a closer look. For Git operations we’re using the JGit library, and this problem with worktrees is a known issue in their bug tracking system. It seems a fix is in progress, with important activity this year. Once they release the fix, we can update our dependency. I’m afraid we can’t do more at this point.
Is there no way to work around this in the meantime? JGit doesn’t seem in any hurry to fix this. You might be able to resolve the gitdir from the worktree yourself and pass that to JGit
This also is reproducible with the sonar VS code extension on a Mac. For a commercial product to let this go years with no solution is really poor customer service. Stop using jgit or at least provide a work-around that does not involve stopping using git worktrees.
[Info - 17:34:17.149] Analyzing 7 files...
Folder file:///Users/me/development/work/client/dev is now on branch dev_fixStuff
[Error - 17:34:17.534] Couldn't access repository for path /Users/me/development/work/client/dev
[Error - 17:34:17.535] org.eclipse.jgit.errors.RepositoryNotFoundException: repository not found: /Users/me/development/work/client/master/.git/worktrees/dev
at org.eclipse.jgit.lib.BaseRepositoryBuilder.build(BaseRepositoryBuilder.java:627)
at org.sonarsource.sonarlint.core.vcs.GitUtils.getRepositoryForDir(GitUtils.java:59)
at org.sonarsource.sonarlint.ls.folders.WorkspaceFolderBranchManager.lambda$didBranchNameChange$1(WorkspaceFolderBranchManager.java:80)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:833)
It looks like this can be worked around by passing -Dsonar.scm.disabled=true to sonarqube-scanner, an option that appears to be entirely undocumented and I really wish I hadn’t had to find myself by tearing apart the source code.