Closed chenlish closed 1 year ago
ReportGenerator reads the code files that appear in your coverage.cobertura.xml
file(s).
I guess one code file has the path 'https://dev.azure.com/{repo}/_apis/git/repositories/{repo}/items?api-version=1.0&versionType=commit&version=xxxxxxx&path={file}''.
Perhaps you can have a look at the coverage.cobertura.xml
file(s). Does is contain the url?
ReportGenerator reads the code files that appear in your
coverage.cobertura.xml
file(s). I guess one code file has the path 'https://dev.azure.com/{repo}/_apis/git/repositories/{repo}/items?api-version=1.0&versionType=commit&version=xxxxxxx&path={file}''.Perhaps you can have a look at the
coverage.cobertura.xml
file(s). Does is contain the url?
thanks for your quick response. Yes, the 'coverage.cobertura.xml' file contains the url. like:
<class name="" filename="{url here}" line-rate="0" branch-rate="0" complexity="6">
because the git commit does not include those files, so it will throw errors here. does this url generated by the reportGenerator? how can i config the reportGenerator parameters to resolve it?
thanks.
The url is not generated by ReportGenerator. It's generated by your code coverage tool (e.g. coverlet).
Please have a look at my comment here: https://github.com/danielpalme/ReportGenerator/issues/501#issuecomment-1073008102
This comment describes how you can create a "Personal/System access token" and pass the token to ReportGenerator.
With this token, ReportGenerator will be able to access the file.
@danielpalme resolved. help me a lot. thanks.
I've had a similar issue, which I posted about under another issue ticket. https://github.com/danielpalme/ReportGenerator/issues/640
But this one seems more appropriate.
In summary, when our projects were targeting .net 6, we saw no issues from report generator. When we switched the projects to use .net 8, we saw the issues above "error reading file
Due to the issue reading the files, this in-turn caused problems with our SonarQube analysis steps.
Thanks to the tips in this post, we looked at the Cobertura.xml files, and compared the .net 6 and .net 8 output.
.net 6 Cobertura.xml
For each class listed, the xml showed class name
and filename
but with filename being an actual file path i.e. no URI
.net 8 Cobertura.xml
Here, the xml showed class name
and filename
again, but the filename also contained the URI information.
filename="URI;path=/path/to/file.cs"
This led us to question the <UseSourceLink>true</UseSourceLink>
setting in our cicd.runsettings
file. This has been set to true
for a very long time and across a great number of projects - with no issues, but crucially, all projects at .net 6.
We then set <UseSourceLink>false</UseSourceLink>
and re-ran the build (.net 8) and there were no "Error reading file..." errors.
So we have resolved the issue by changing the UseSourceLink setting.
We tried different versions of the coverlet.collector, (version 3.1.2 and 6.0.2). We still needed to set UseSourceLink = false, for the Cobertura XML file to be generated in such a way that Report Generator could process it without the "Error reading file " message.
Hope this helps others that hit this problem.
@AL71B
I tried to reproduce this with a runsettings
file. But the Cobertura file did not change.
Can you create a minimal sample project? Then I can have a closer look.
Describe the bug Error during reading file: '[https://dev.azure.com/{repo}/_apis/git/repositories/{repo}/items?api-version=1.0&versionType=commit&version=xxxxxxx&path={file}']
To Reproduce azure devops task hosted latest linux net6.0
I have no idea on why reading file from a special commit when generate code coverage. how can i fix this problem?