ERROR: Cannot save config file 'FileBasedConfig[/home/vsts/.config/jgit/config]


We are attempting to run the sonarcloud scans in our DevOps Pipelines on a self-hosted Azure Agent, as opposed to an Azure-hosted agent. This all works perfectly fine on the Azure-hosted agent, but we keep getting an error on the self-hosted.

The error occurs during the “SonarCloudAnalyze@1” task in our yaml pipeline.

INFO: Load metrics repository (done) | time=675ms
##[error]ERROR: Cannot save config file 'FileBasedConfig[/home/vsts/.config/jgit/config]' Creating directories for /home/vsts/.config/jgit failed
at org.eclipse.jgit.util.FileUtils.mkdirs(
at org.eclipse.jgit.util.FS$FileStoreAttributes.saveToConfig(
at org.eclipse.jgit.util.FS$FileStoreAttributes.lambda$4(
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(
at java.base/java.util.concurrent.ThreadPoolExecutor$
at java.base/

The issues seems to be that the “vsts” path only exists on Azure-hosted Agents, but I cannot find any documentation on how to specify a different, working path. The output for other tasks appears to go an “agent” path: “TypeScript configuration file /agent/_work/1/s/…”.

I’ve searched, and seen similar topics, but none that seem to apply directly. Any help would be greatly appreciated.


I was not able to reproduce your issue, could you please give me more details about your project, what is the language? Could you also share your yaml config file?

Hello and thanks for your reply.
The trouble with reproducing it is that it works fine in a pipeline running on an Azure Hosted agent. It’s only when I switch to self-hosted that we get the error.

The project language is Angular TS.

The config is:

- task: SonarCloudPrepare@1
              SonarCloud: ''
              organization: 'xxxx'
              scannerMode: 'CLI'
              configMode: 'file'
              cliProjectKey: 'xxxx-retail'
              cliProjectName: 'xxxx :: Retail'
              cliSources: '$(System.DefaultWorkingDirectory)'
              enabled: true
- task: SonarCloudAnalyze@1
            enabled: true

          - task: SonarCloudPublish@1
            enabled: true # turn this back on when portal based one is removed
              pollingTimeoutSec: '300'
  **/polyfills.ts, \
  **/main.ts, \
  **/test-setup.ts, \
  **/test.ts, \
  **/**.spec.ts, \
  **/**.fixture.ts, \
  **/specs/**, \
  **/e2e/**, \
  **/test-utils.ts, \
  **/test-utils/**, \
  **/jest.config.js, \
  **/karma.conf.js, \
  **/mock-providers.ts, \
  **/**.module.ts, \
  **/environments/**, \
  **/app-module-imports.ts, \
  **/**.providers.ts, \
  libs/shared/feature/**, \
  apps/retail-app/**/*, \
  libs/retail/feature/**/*, \
  **/**.provider.ts, \

Few more information I need:

  • What is the OS system of the self-hosted agent you are using?
  • Could you please send me the full scanner logs from a failing analysis and a successful analysis so I can compare them? You can run scanner with -x to get more detailed logs. And I can start a private channel if you want to share them privately.

Thanks a lot

Both agents have Ubuntu as the OS.

I’m using the built-in ADO task, does the “-x” work with that or would I need to script it differently?

- task: SonarCloudAnalyze@1
            enabled: true

I’d be happy to provide the logs in a private channel. Thanks again for your help.

You can add the following code at the beginning of you yaml file to enable debugging logs:

- name: system.debug
  value: true

It will add debug to all tasks so your pipeline will take longer to execute.
I will start a private conversation so you can share your logs.

Good News! We were able to resolve the error by creating the “vsts” path on the self-hosted agent, under home, and then granting Read/Write access to that path.

So my issue appears to be fixed, but I’m still curious why that vsts path was chosen, or where it came from. Is that a path that could be adjusted with parameters?

Thanks again

Great news. Thanks a lot for sharing. Unfortunately, the path is not something adjustable.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.