Closed Blast545 closed 4 years ago
We've experienced this issue as well and it seems to be from an upstream change in colcon-core
.
@dirk-thomas I've been playing around with the versioning and it seems to be an issue introduced in v0.5.0.
You can see the issue we've been using to track it ros-security/aws-oncall#48.
It looks like the directory in which lcov
is executed changes from the root directory to the package directory.
The issue specifically occurs when setting the cwd
in check_call.
@piraka9011 I am neither the author not the maintainer of this package. So someone else will need to look into this.
The error seems to come from this line: https://github.com/colcon/colcon-lcov-result/blob/42bc4249ba159a3e30e478fbb708064e218e9cea/colcon_lcov_result/task/lcov.py#L63 From: https://github.com/colcon/colcon-core/blob/e45426e63602db19eb0084bd253d04c973af8ab6/colcon_core/package_descriptor.py#L44
It seems that pkg.path
is already a pathlib.Path
object, so just doing:
pkg.path.absolute()
should solve the problem.
note: resolve()
can be used instead of absolute, which also resolves symbolik links.
But I'm thinking that it might make more sense to do the fix in the PackageDescriptor
class, instead of applying the fix only to lcov. I'm unsure if resolving the path can create a problem in other places, @dirk-thomas what do you think?
But I'm thinking that it might make more sense to do the fix in the PackageDescriptor class, instead of applying the fix only to lcov. I'm unsure if resolving the path can create a problem in other places, @dirk-thomas what do you think?
Replying to myself after seeing https://github.com/colcon/colcon-core/pull/283. Guess that lcov should be fixed by using pkg.realpath.
@ivanpauno I'm not too familiar with developing colcon extensions but if you think you have the solution do you mind opening a PR for this?
Note that the previous behavior was that lcov
was being executed from the root workspace directory as opposed to the package directory so I don't think we should be modifying the --base-directory
.
I can confirm that running lcov
from the root workspace directory with the same arguments passed in lcov.py
works properly.
Using the recommended workflow listed here: https://github.com/colcon/colcon-lcov-result to generate lcov results in a ros workspace, the extension is not working properly because there seems to be a problem with the paths used in the lcov expanded command.
These are the commands to reproduce the problem:
These won't generate any result in the ~/ros_ws/build/ament_index_cpp/coverage_base.info file. Using the proposed workflow listed here: https://github.com/colcon/colcon-mixin-repository/pull/8 I get the coverage results without problems.
By inspecting the output of the extension, using debug log level, when running colcon lcov-result --log-level debug --packages-select ament_index_cpp --initial I get:
Partial result of the command
DEBUG:colcon.colcon_core.event_handler.log_command:Invoked command in 'src/ament/ament_index/ament_index_cpp' returned '0': /usr/bin/lcov --gcov-tool /usr/bin/gcov --base-directory src/ament/ament_index/ament_index_cpp --capture --directory /home/$USER/ros_ws/build/ament_index_cpp --output-file /home/$USER/ros_ws/build/ament_index_cpp/coverage_base.info --config-file /home/$USER/.local/lib/python3.6/site-packages/colcon_lcov_result/verb/configuration/lcovrc --initial --rc lcov_branch_coverage=0And using thisrc/ament/ament_index/ament_index_cpps command directly on the main workspace folder (ros_ws) generates the coverage initial files correctly. There is a bug related to the fact that the --base-directory path used is relative and it should be a full path instead.