Extension not finding build results generated

[Blast545]

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:

colcon build --symlink-install --mixin coverage-gcc --packages-select ament_index_cpp
colcon lcov-result --log-level debug --packages-select ament_index_cpp --initial

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=0

And 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.

[piraka9011]

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.

[dirk-thomas]

@piraka9011 I am neither the author not the maintainer of this package. So someone else will need to look into this.

[ivanpauno]

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?

[ivanpauno]

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.

[piraka9011]

@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.