All files excluded by SCM ignore settings

kapman · November 25, 2024, 9:17am

SonarQube server: Developer Edition v10.7 (Docker deploy with Nomad)

I am trying to setup SonarQube Developer Edition for my org and have an instance up and running (got the license recently). I have hit a wall with running an analysis for my repos wherein all files are getting excluded due to SCM ignore settings. I found few posts regarding the same but nothing has worked for me so far except for using the setting *sonar.scm.exclusions.disabled* set to true which basically strips off all the blame information and then pull request decoration also does not work correctly as it fails to identify new code after the last version.

Projects that I am analyzing are Java Spring boot apps built with Gradle 7+. I have tried running scans both locally and via Github Actions but without vain. Updating or deleting gitignore file also did not have any effect.

Command used to run scan : ./gradlew sonar

I have also tried to use various properties like sonar.inclusions, sonar.sources etc without any effect. Any help here would be greatly appreciated.

Note: Login to sonarqube is through Okta (SAML) and not delegated to Github, so the user SCM account is set to their email which may/maynot be linked to their Github account. I am not sure if this could be an issue.

I can share specific logs if needed (since the log is too long when I run with --debug). Here is a brief snippet from the scan logs

2024-11-25T13:33:43.534+0530 [INFO] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] Branch name: sonar-test
2024-11-25T13:33:43.538+0530 [DEBUG] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] Declared patterns of language Kubernetes were converted to sonar.lang.patterns.kubernetes : 
2024-11-25T13:33:43.538+0530 [DEBUG] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] Declared patterns of language CSS were converted to sonar.lang.patterns.css : **/*.css,**/*.less,**/*.scss,**/*.sass
2024-11-25T13:33:43.538+0530 [DEBUG] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] Declared patterns of language Scala were converted to sonar.lang.patterns.scala : **/*.scala
2024-11-25T13:33:43.538+0530 [DEBUG] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] Declared patterns of language JSP were converted to sonar.lang.patterns.jsp : **/*.jsp,**/*.jspf,**/*.jspx
2024-11-25T13:33:43.538+0530 [DEBUG] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] Declared patterns of language JavaScript were converted to sonar.lang.patterns.js : **/*.js,**/*.jsx,**/*.cjs,**/*.mjs,**/*.vue
2024-11-25T13:33:43.538+0530 [DEBUG] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] Declared patterns of language Python were converted to sonar.lang.patterns.py : **/*.py
2024-11-25T13:33:43.539+0530 [DEBUG] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] Declared patterns of language Docker were converted to sonar.lang.patterns.docker : **/Dockerfile,**/*.dockerfile
2024-11-25T13:33:43.539+0530 [DEBUG] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] Declared patterns of language PL/SQL were converted to sonar.lang.patterns.plsql : **/*.sql,**/*.pks,**/*.pkb
2024-11-25T13:33:43.539+0530 [DEBUG] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] Declared patterns of language Dart were converted to sonar.lang.patterns.dart : **/*.dart
2024-11-25T13:33:43.539+0530 [DEBUG] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] Declared patterns of language Java were converted to sonar.lang.patterns.java : **/*.java,**/*.jav
2024-11-25T13:33:43.539+0530 [DEBUG] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] Declared patterns of language HTML were converted to sonar.lang.patterns.web : **/*.html,**/*.xhtml,**/*.cshtml,**/*.vbhtml,**/*.aspx,**/*.ascx,**/*.rhtml,**/*.erb,**/*.shtm,**/*.shtml,**/*.cmp,**/*.twig
2024-11-25T13:33:43.539+0530 [DEBUG] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] Declared patterns of language Flex were converted to sonar.lang.patterns.flex : **/*.as
2024-11-25T13:33:43.539+0530 [DEBUG] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] Declared patterns of language XML were converted to sonar.lang.patterns.xml : **/*.xml,**/*.xsd,**/*.xsl,**/*.config
2024-11-25T13:33:43.539+0530 [DEBUG] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] Declared patterns of language JSON were converted to sonar.lang.patterns.json : **/*.json
2024-11-25T13:33:43.539+0530 [DEBUG] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] Declared patterns of language IPython Notebooks were converted to sonar.lang.patterns.ipynb : **/*.ipynb
2024-11-25T13:33:43.539+0530 [DEBUG] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] Declared patterns of language Text were converted to sonar.lang.patterns.text : 
2024-11-25T13:33:43.539+0530 [DEBUG] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] Declared patterns of language VB.NET were converted to sonar.lang.patterns.vbnet : **/*.vb
2024-11-25T13:33:43.539+0530 [DEBUG] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] Declared patterns of language CloudFormation were converted to sonar.lang.patterns.cloudformation : 
2024-11-25T13:33:43.539+0530 [DEBUG] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] Declared patterns of language Swift were converted to sonar.lang.patterns.swift : **/*.swift
2024-11-25T13:33:43.539+0530 [DEBUG] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] Declared patterns of language YAML were converted to sonar.lang.patterns.yaml : **/*.yaml,**/*.yml
2024-11-25T13:33:43.540+0530 [DEBUG] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] Declared patterns of language C++ were converted to sonar.lang.patterns.cpp : **/*.cc,**/*.cpp,**/*.cxx,**/*.c++,**/*.hh,**/*.hpp,**/*.hxx,**/*.h++,**/*.ipp,**/*.ixx,**/*.mxx,**/*.cppm,**/*.ccm,**/*.cxxm,**/*.c++m
2024-11-25T13:33:43.540+0530 [DEBUG] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] Declared patterns of language C were converted to sonar.lang.patterns.c : **/*.c,**/*.h
2024-11-25T13:33:43.540+0530 [DEBUG] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] Declared patterns of language Go were converted to sonar.lang.patterns.go : **/*.go
2024-11-25T13:33:43.540+0530 [DEBUG] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] Declared patterns of language Kotlin were converted to sonar.lang.patterns.kotlin : **/*.kt,**/*.kts
2024-11-25T13:33:43.540+0530 [DEBUG] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] Declared patterns of language T-SQL were converted to sonar.lang.patterns.tsql : **/*.tsql
2024-11-25T13:33:43.540+0530 [DEBUG] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] Declared patterns of language Secrets were converted to sonar.lang.patterns.secrets : 
2024-11-25T13:33:43.540+0530 [DEBUG] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] Declared patterns of language Ruby were converted to sonar.lang.patterns.ruby : **/*.rb
2024-11-25T13:33:43.540+0530 [DEBUG] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] Declared patterns of language C# were converted to sonar.lang.patterns.cs : **/*.cs,**/*.razor
2024-11-25T13:33:43.540+0530 [DEBUG] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] Declared patterns of language PHP were converted to sonar.lang.patterns.php : **/*.php,**/*.php3,**/*.php4,**/*.php5,**/*.phtml,**/*.inc
2024-11-25T13:33:43.540+0530 [DEBUG] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] Declared patterns of language Terraform were converted to sonar.lang.patterns.terraform : **/*.tf
2024-11-25T13:33:43.540+0530 [DEBUG] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] Declared patterns of language AzureResourceManager were converted to sonar.lang.patterns.azureresourcemanager : **/*.bicep
2024-11-25T13:33:43.540+0530 [DEBUG] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] Declared patterns of language ABAP were converted to sonar.lang.patterns.abap : **/*.abap,**/*.ab4,**/*.flow,**/*.asprog
2024-11-25T13:33:43.541+0530 [DEBUG] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] Declared patterns of language Objective-C were converted to sonar.lang.patterns.objc : **/*.m
2024-11-25T13:33:43.541+0530 [DEBUG] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] Declared patterns of language TypeScript were converted to sonar.lang.patterns.ts : **/*.ts,**/*.tsx,**/*.cts,**/*.mts
2024-11-25T13:33:43.548+0530 [INFO] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] Preprocessing files...
2024-11-25T13:33:43.564+0530 [DEBUG] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] loading config FileBasedConfig[/Users/kapil-mangtani/.config/jgit/config]
2024-11-25T13:33:43.567+0530 [DEBUG] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] readpipe [bash, --login, -c, which git],/Users/kapil-mangtani
2024-11-25T13:33:43.610+0530 [DEBUG] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] readpipe may return '/usr/bin/git'
2024-11-25T13:33:43.610+0530 [DEBUG] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] remaining output:

2024-11-25T13:33:43.610+0530 [DEBUG] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] readpipe [xcode-select, -p],/Users/kapil-mangtani
2024-11-25T13:33:43.630+0530 [DEBUG] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] readpipe may return '/Library/Developer/CommandLineTools'
2024-11-25T13:33:43.630+0530 [DEBUG] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] remaining output:

2024-11-25T13:33:43.630+0530 [DEBUG] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] readpipe [/usr/bin/git, --version],/usr/bin
2024-11-25T13:33:43.672+0530 [DEBUG] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] readpipe may return 'git version 2.39.3 (Apple Git-146)'
2024-11-25T13:33:43.672+0530 [DEBUG] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] remaining output:

2024-11-25T13:33:43.672+0530 [DEBUG] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] readpipe [/usr/bin/git, config, --system, --show-origin, --list, -z],/usr/bin
2024-11-25T13:33:43.706+0530 [DEBUG] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] readpipe may return 'null'
2024-11-25T13:33:43.706+0530 [DEBUG] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] remaining output:

2024-11-25T13:33:43.707+0530 [DEBUG] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] readpipe rc=128
2024-11-25T13:33:43.708+0530 [DEBUG] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] Exception caught during execution of command '[/usr/bin/git, config, --system, --show-origin, --list, -z]' in '/usr/bin', return code '128', error message 'fatal: unable to read config file '/etc/gitconfig': No such file or directory
'
2024-11-25T13:33:43.708+0530 [DEBUG] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] loading config FileBasedConfig[/Users/kapil-mangtani/.config/git/config]
2024-11-25T13:33:43.708+0530 [DEBUG] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] loading config UserConfigFile[/Users/kapil-mangtani/.gitconfig]
2024-11-25T13:33:43.750+0530 [DEBUG] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] 95 non excluded files in this Git repository
2024-11-25T13:33:43.754+0530 [DEBUG] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] File '/Users/kapil-mangtani/IdeaProjects/xxx/metrics/ApplicationInformationInstrumentation.java' is excluded by the scm ignore settings.
2024-11-25T13:33:43.754+0530 [DEBUG] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] File '/Users/kapil-mangtani/IdeaProjects/xxxmetrics/HealthMetricsConfiguration.java' is excluded by the scm ignore settings.
...988 similar logs

2024-11-25T13:33:43.805+0530 [INFO] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] 0 languages detected in 0 preprocessed files
2024-11-25T13:33:43.805+0530 [INFO] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] 990 files ignored because of scm ignore settings
2024-11-25T13:33:43.806+0530 [INFO] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] Loading plugins for detected languages
2024-11-25T13:33:43.806+0530 [DEBUG] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] Detected languages: []
2024-11-25T13:33:43.806+0530 [INFO] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] Load/download plugins
2024-11-25T13:33:43.806+0530 [INFO] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] Load/download plugins (done) | time=0ms
2024-11-25T13:33:43.806+0530 [DEBUG] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] Optional language-specific plugins not loaded: [abap, csharp, cpp, cfamilydependencies, dbd, dbdjavafrontend, dbdpythonfrontend, flex, go, web, javasymbolicexecution, java, javascript, kotlin, php, plsql, python, ruby, sonarscala, swift, tsql, vbnet, security, securitycsharpfrontend, securityjsfrontend, securityjavafrontend, securityphpfrontend, securitypythonfrontend, dart]
2024-11-25T13:33:43.806+0530 [DEBUG] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] No plugins loaded

2024-11-25T13:33:44.122+0530 [INFO] [org.sonarsource.scanner.lib.internal.ScannerEngineLauncher] 0 files indexed

Colin · November 26, 2024, 8:07am

Hey there.

sonar.scm.exclusions.disabled will not remove SCM information or affect PR decoration, however sonar.scm.disabled=false will. Are you perhaps getting confused, or setting both?

kapman · November 26, 2024, 8:37am

I am not setting both the properties. SCM is enabled and when I run a scan without sonar.scm.exclusions.disabled=true, all files get excluded by SCM ignore settings (Idk what these settings are because even after deleting my gitignore file, I get the same log).

But when I run a scan with sonar.scm.exclusions.disabled=true, the scan does not exclude any files but then I see a different log (missing blame information) like

SCM Publisher SCM provider for this project is: git
SCM Publisher 26 source files to be analyzed
SCM Publisher 0/26 source files have been analyzed (done) | time=48ms
Missing blame information for the following files:
  * src/test/java/com/xxx_api/service/impl/MemberServiceImplTest.java
  * src/main/java/com/xxx_api/service/impl/MemberServiceImpl.java
  * src/main/java/com/xxx_api/activities/MemberEntityActivities.java
* + many others
This may lead to missing/broken features in SonarQube
CPD Executor 72 files had no CPD blocks
CPD Executor Calculating CPD for 77 files
CPD Executor CPD calculation finished (done) | time=22ms

So I assume this means that sonar cannot report code coverage or issues on NEW code since it is missing blame information. Also see the screenshot below from the pull request decoration and sonarqube instance (it does not show coverage or duplication information and says 0 New lines)

Am I missing something here?

Colin · November 26, 2024, 10:43am

Missing blame information could come from a number of sources.

What CI are you running your analysis in? Is it GitHub Actions? If so, could you share your GitHub Actions pipeline YML?

kapman · November 26, 2024, 11:00am

Yes I am using Github Actions, but I also tried running the analysis locally using a token for debugging. Let me share both yaml and local commands used.

Following is Github Action yaml

name: SonarQube Analysis

on:
  push:
    branches:
      - develop
  pull_request:
    types: [opened, synchronize, reopened]

jobs:
  build:
    name: Build and analyze
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0  # Shallow clones should be disabled for a better relevancy of analysis
      - name: Setup Java
        uses: actions/setup-java@v4
        with:
          java-version-file: ${{ github.workspace }}/.java-version
          distribution: 'zulu' # Alternative distribution options are available.
      - name: Cache SonarQube packages
        uses: actions/cache@v4
        with:
          path: ~/.sonar/cache
          key: ${{ runner.os }}-sonar
          restore-keys: ${{ runner.os }}-sonar
      - name: Cache Gradle packages
        uses: actions/cache@v4
        with:
          path: ~/.gradle/caches
          key: ${{ runner.os }}-gradle-${{ hashFiles('**/*.gradle') }}
          restore-keys: ${{ runner.os }}-gradle
      - name: Build and analyze
        env:
          GITHUB_TOKEN: ${{ secrets.GH_ORG_TOKEN }}
          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
          SONAR_HOST_URL: ${{ secrets.SONAR_HOST_URL }}
        run: ./gradlew clean build jacocoTestReport sonar --info

And when doing it locally,

./gradlew clean build jacocoTestReport sonar \
  -Dsonar.token=sqp_my_token_73d97342 \
  -Dsonar.verbose=true —debug

I am seeing the same log in both the cases

Colin · November 27, 2024, 8:17am

It’s weird to see a GitHub Actions Pipeline missing blame data when fetch-depth is set to 0. It’s less weird to see that on a local run where there might be local changes not checked into git.

Is there any chance your Gradle build has any some strange tasks a part of it that might be nuking some information (like the .git folder) during the build?

kapman · November 28, 2024, 7:55am

I am not sure. I downloaded the jgit command line distribution and ran the following command

org.eclipse.jgit.pgm-7.0.0.202409031743-r.sh blame -w <path-to-file>

If I specify a file present in the root of the project, I am able to see the blame information. BUT if I specify path to a file under a directory (e.g java source code files located under my-api/src/main/etc), I get the following error

fatal: no such path 'my-api/src/main/java/com/etc' in HEAD

If I instead run git blame <path-to-file>, I can see the blame information for any path I provide. Is this an issue with the Jgit or the gradle plugin? I am trying to create a fresh repository to see if this issue can be reproduced there or not.

UPDATE:
The directory structure seems to have an impact on the SCM or blame collection information (verified with JGit tool). My current directory structure is as follows:

my-api
    .github/
    .idea/
    gradle/
    .gitignore
    settings.gradle
    my-api
        build.gradle
        src
            main
                java
                    com.example
                        Application.java

With this structure, when I run an analysis all files get excluded (error I get is “all files ignored due to SCM ignore settings”). If I add the property scm.exclusions.disabled=true, files are indexed but then I get the error related to Missing Blame information for ALL the files. Running jgit blame -w on the java files also return a fatal path error.

However, if I change my directory structure to the following, I get no issues at all (not even SCM ignore settings). All the files are properly indexed and even jgit returns proper blame information.

my-api
    .github/
    .idea/
    gradle/
    .gitignore
    settings.gradle
    build.gradle
    src
        main
            java
                com.example
                    Application.java

I then tried to follow this documentation for multi project build and also this sample but then again all files got ignored due to SCM ignore settings. This time, setting the scm.exclusions.disabled=true also did not help. So the question is , does sonarqube not work well with multi module projects with gradle?

Colin · November 28, 2024, 10:30am

We have some experts on both these topics I’m going to call in. Thanks for the thorough explanation.

kapman · December 4, 2024, 6:33am

Do we have an update on this?

Colin · December 7, 2024, 8:35am

Not yet! The end of the year gets pretty busy. Thanks for your patience.

kapman · December 9, 2024, 4:41pm

Adding some further information here.

I have been looking into different JGit versions (since sonarqube uses JGit to collect blame information) and what I have found that the blame command works correctly till JGit version 5.5.1 (which was released in 2019). Any version beyond 5.5.1 fails to collect blame information for a multi module gradle project.

How I tested this?

I ran the following command

/Users/kapil-mangtani/Downloads/org.eclipse.jgit.pgm-5.5.1.201910021850-r.sh blame -w my-api/src/main/java/com/company/my_api/Application.java

This correctly returns the blame information. But when I use any other version of JGit, eg.

/Users/kapil-mangtani/Downloads/org.eclipse.jgit.pgm-7.0.0.202409031743-r.sh blame -w my-api/src/main/java/com/company/my_api/Application.java

returns an error `fatal: no such path ‘xxxx/path/mentioned/above’ in HEAD

I tested the same using the JGit jar using the below code:

public class Jgit {

    static final String REPO = "/Users/kapil-mangtani/IdeaProjects/my-api/.git";
    static final String PATH1 = ".java-version";
    static final String PATH2 = ".github/workflows/build-deploy-dev.yml";
    static final String PATH3 = "my-api/src/main/java/com/company/my_api/Application.java";

    public static void main(String[] args) throws Exception {
        FileRepositoryBuilder builder = new FileRepositoryBuilder();
        Git git = new Git(builder.setGitDir(new File(REPO1)).readEnvironment().findGitDir().build());

        BlameCommand blameCommand = git.blame().setFilePath(PATH1);
        BlameResult result = blameCommand.call();
        assert result != null;   // TRUE

        BlameCommand blameCommand1 = git.blame().setFilePath(PATH2);
        BlameResult result1 = blameCommand1.call();
        assert result1 != null;  // TRUE

        BlameCommand blameCommand2 = git.blame().setFilePath(PATH3);
        BlameResult result2 = blameCommand2.call();
        assert result2 != null;  // FALSE for versions above 5.5.1
    }

Colin · December 9, 2024, 4:54pm

Hey @kapman

Great investigatory work. Have you considered filing an issue on Issues · eclipse-jgit/jgit · GitHub?

kapman · December 10, 2024, 7:30am

@Colin I have opened an issue on JGit’s Github repo, Blame command returns null result for gradle module · Issue #119 · eclipse-jgit/jgit · GitHub

However, I would appreciate it if Sonar’s engineering team takes a look at it and verifies the issue on their side as well. If this is actually an issue, SonarQube’s team should fix it without waiting for JGit’s issue to be resolved first.

We purchased the Developer Edition license because we wanted to leverage the Pull Request Decoration feature, and we have not been able to utilize it because of this missing blame information issue. Which is why I am hoping this gets escalated and a resolution is provided soon.

In the meantime, if you can let me know what version of sonarqube server, uses JGit 5.5.1 or lower, I can test it out and check if we can downgrade our sonarqube server instance to make it work until the issue is resolved.

Colin · December 10, 2024, 7:38am

Probably SonarQube v8.2, released in 2020. I would not recommend using this EOL version.

It’s very strange someone else hasn’t run into this. Let’s see who gets to it first – our developers or the JGit devs!

kapman · December 10, 2024, 7:54am

Yes, even I am surprised that this has not been brought up.

Is there also an issues page in sonarqube where I can create an issue similar to Jgit’s? It would be helpful for me to track progress.

Colin · December 11, 2024, 9:13am

You can consider this Community the issues page, until a real ticket is created in our Jira project.

kapman · December 16, 2024, 12:25pm

Update:

I have now narrowed down the issue to using a specific gradle plugin. In our case, we are using a gradle plugin to manage Git hooks in all of our repositories and removing this plugin fixes the issue. This issue is particular to JGit as the blame command doesn’t work with this plugin (but the blame command works for JGIT versions less than or equal to 5.5.1 even when this plugin is used, smh). So when this gets fixed by JGit, sonar scans should work as normal.

@Colin It might be worth adding this information to sonarqube’s documentation if the team agrees and hope they start looking at alternatives to JGit in the future

Colin · December 16, 2024, 12:56pm

Hey @kapman

Thanks for the information!

I’m not sure this is a great candidate for inclusion in our docs since this plugin doesn’t appear to be very popular. That being said, we’ll watch for any more similar reports (Gradle projects that fail to have blame data collected) and reconsider if there are more reports before JGit fixes the issue (if they choose to)

Do you face any other issues with JGit that make you believe we should look at alternatives?