action #71095
closed[ci][os-autoinst] unable to read files in codecov reports, probably due to "opt" prefix
Description
Observation¶
https://codecov.io/gh/os-autoinst/os-autoinst/pull/1529/changes mentions
Changes in opt/consoles/localXvnc.pm
Changes in opt/commands.pm
Changes in opt/consoles/console.pm
but opening the folded bars does not reveal the source code context, probably due to the "opt/" prefix
Suggestions¶
Probably this is a regression introduced by the switch to CMake introducing the "opt/" prefix. https://docs.codecov.io/docs/fixing-paths has some suggestions but I would prefer if we strip the "opt/" in the CI build even in before.
Updated by tinita over 3 years ago
This seems to have been caused by https://github.com/os-autoinst/os-autoinst/pull/1293
See my comment
https://github.com/os-autoinst/os-autoinst/pull/1293#pullrequestreview-483960680
I don't understand why the directory was changed, but this should be fixable in codecov.yml by adjusting the path:
fixes:
- "/opt/run/::"
Updated by tinita over 3 years ago
- Status changed from Workable to In Progress
- Assignee set to tinita
Updated by tinita over 3 years ago
- Status changed from In Progress to Feedback
Updated by okurz over 3 years ago
tinita wrote:
I don't understand why the directory was changed
not by intention for sure :)
but this should be fixable in
codecov.ymlby adjusting the path
mkittler reported that when generating a coverage report locally the paths are also not correct. So your change will certainly fix codecov but we should look into the other issue as well which might again impact how codecov can handle this.
Updated by okurz over 3 years ago
https://github.com/os-autoinst/os-autoinst/pull/1530 was merged. https://codecov.io/gh/os-autoinst/os-autoinst/pull/1530/changes shows a lot of changes.
I realized that our project still links to outdated reports for coveralls -> #71323
Updated by okurz over 3 years ago
- Status changed from Feedback to Resolved
And as https://codecov.io/gh/os-autoinst/os-autoinst/src/master/autotest.pm looks fine I consider the original issue as gone. For me locally generated coverage reports are ok as well so I do not know if there would be an additional issue. That should be solved as part of another ticket in that case.