- SonarQube Server: 6.7.5 (build 38563)
- Scanner (SonarQube Gradle Plugin): org.sonarsource.scanner.gradle:sonarqube-gradle-plugin:2.8
- SonarQube Git Plugin: 1.9 (build 1725)
- Bamboo: 6.8.1 (build 60805)
- Sonar4Bamboo Bamboo Plugin: 1.7.11 (last free version)
- No blame information is available in SonarQube.
- The logs indicate that blame information is not retrieved due to a linked repository being used.
build 21-Nov-2019 20:02:09 > Task :sonarqube build 21-Nov-2019 20:02:09 SCM provider for this project is: git build 21-Nov-2019 20:02:09 141 files to be analyzed build 21-Nov-2019 20:02:09 This repository references another local repository which is not supported. You can avoid borrow objects from another local repository by not using --reference or --shared when cloning it. build 21-Nov-2019 20:02:09 Missing blame information for the following files: …
- The blame information should be read from the linked repository, rather than the SonarQube Git Plugin failing early due to the linked repository. Fully-cloning repositories is slow, and we do not want to maintain an additional long-running repository directory for these scans – we want to start with a clean directory for each scan. Linked repositories (like those used by default with Bamboo) have facilitated this for us until the recent SonarQube Git Plugin update.
Steps to reproduce:
- Create a git project with Gradle using the given SonarQube Gradle Plugin
- Commit code to a branch
- Create a Bamboo build plan using Sonar4Bamboo 1.7.11
- Run the build plan for the given branch
- Blame information is not received
- (Option 1) Revert the SonarQube Git Plugin to a prior version without this issue
- (Option 2) Manually force Bamboo to execute a full clone before each build (very slow for large repositories)
It looks like this bug was introduced with SONARSCGIT-34 (specific source changes: bda38aeec2). It appears that these changes were made because of the comments here (Gradle SonarJava scan fails) combined with the JGit bug report here (https://bugs.eclipse.org/bugs/show_bug.cgi?id=541050).
It sounds like it comes down to the JGit bug not being fixed, so I wonder if this has to wait until that’s fixed.