Issues after moving from windows to linux agent in our ADO CI pipeline

Version: Enterprise Edition Version 9.6.1 (build 59531)

We have recently moved from using windows agents to linux in our azure devops CI pipeline where we are running sonarqube.
After this move to running on linux environment we have had to do several changes to get things working, one example is how to collect code coverage with “dotnet test”. We added the arguments --collect:"XPlat Code Coverage" -- DataCollectionRunSettings.DataCollectors.DataCollector.Configuration.Format=opencover' and updated SQ prepare with correct opencover.reportsPaths. This has increased our dotnet test execution times (expected) and decreased the SQ analysis time.

However, in the SQ analysis step we sometimes (not all the time for some reason…) see an error about a jgit config path not existing:

##[error]ERROR: Cannot save config file 'FileBasedConfig[/home/masteris/.config/jgit/config]'

This is only logged as an error, but the pipeline step is not failing and SQ seems to be able to continue. So I don’t know if this is an error that affects the SQ analysis?

After analysis and when the result is published we see that it is different compared to before. Code coverage % is lower, lines to cover is higher and for some reason one project is not reporting any coverage at all (but it should and did display it correctly before). These three metrics can of course be related, and the root problem might be that it is just this one project that is not being analyzed and displayed as having no code coverage at all by SQ.

Can you give me some insights into what I can do to get SQ to work properly again now that we have moved to linux agents in devops?

Let me know what more info you need to understand our problems.

Thanks in advance!

No one with any ideas how to solve this or investigate it further?

Hello @Emil_Ahlqvist thanks a lot for taking the time to participate in the community.

Please could you try the step suggested in that post ?

It is also related to the same error message with linux os on ADO.


Yes, I have seen that thread before. We are using agents on VM Scale Sets, meaning that they are re-created from images and unfortunately creating the vsts path is something we easily can not do.
I have experimented with creating the path everytime our Ci pipeline is run, as one of the first steps in the pipeline. This didn’t work either though.

Any more suggestions? :slight_smile:

Hi @Emil_Ahlqvist,

Sorry for our late answer. Are you still experimenting with the same issue in your analysis?

If yes, it is worth clarifying that you are mentioning 2 different things in your initial thread:

  • You did several changes after the move to Linux agents, related to the coverage computation
  • Also, now you have this error related to jgit config file that can’t be saved

But in the end, your functional problem is the miscomputation of coverage. So here it makes sense to address changes you made about coverage and not the jgit config file error.

So the question is, why did you have to do these changes?:

Have you validated that this behaves as it did before?
It is worth remembering that when a coverage report is given to SonarQube, it becomes the entire source of truth for coverage-related metrics (lines to cover, lines covered, etc.) and so if results are different, it’s because coverage reports are different.


Hello, I’d almost forgotten about this thread - so long ago since it was active :slight_smile:

You are right that I’m mentioning two problems in the initial message. It is difficult for me who is not author of this software to say if that can be related or not though, so I figured it made sense to give as much information as possible… Can you give an explanation why we see the jgit error sometimes? How can we investigate more? How should one fix the issue?

The easy answer why we had to do the changes is because the way we collected code coverage before was platform-dependent on windows, hence --collect: "XPlat… " which is cross platform. We did other changes not related to SQ as well. But without the changes to collect coverage we saw 0 code coverage in SQ. I understand you that the issue can’t be in SQ, but rather in how the coverage is collected, am I right?

Anyway, we dropped this work long ago now since we didnt get help or found any solutions by ourselves and had to move on with other things. I can continue to keep this thred alive if it can help others or give me a better understanding for future work though.

Hi @Emil_Ahlqvist,

Thank you for your answer. You did well to report it all indeed, but yes both are different problems.

You understand it well. If you saw differences, it’s simply because the new method of collecting coverage differs and reports different results. If this is still a focus for you, it has to be investigated during the coverage collection.

As for the JGit issue, it is likely related to the file system: ie. the folder is not present, or the process cannot write into it. You can look into this path to understand what it is about. In any case, the resolution is to make sure it’s possible for the SonarQube scanner to write in there.

Let me know if you find something relevant by looking at this folder properties.


Ok, well if Sonarqube scanner can’t be the problem I understand it as I’m on the wrong forum looking for help.

Thanks for your answers!

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