search

codecov / feedback

A place to discuss feedback about the pull request and web product experience.
38 stars 9 forks source link

"unusable report" for a C project built via autotools/libtool #288

Closed tobiasbrunner closed 7 months ago

tobiasbrunner commented 9 months ago

Describe the bug Our project consists of several libraries/plugins and executables. It's built via autotools (autconf/automake/libtool etc.). We have subdir-objects enabled in configure.ac, which means object and *.gcno/*.gcda files are stored in .libs directories next to the corresponding source files.

It seems that the collector script/action is unable to correctly associate the coverage files with the source files. Neither the old bash script, nor the v3 or v4 GitHub Actions work.

Github Action run with v4, the result is here. The log output and the uploaded data shows a lot of *.gcov paths directly in the repository root, which doesn't seem correct.

Similar in this run with v3 where the log shows coverage stats that look fine, however, the result here shows a lot paths that are basically just file names (no path component) and no source or coverage data. The paths are apparently always relative to the corresponding component's Makefile (library, plugin etc.), not the repository root.

Is this a known limitation? Is there a workaround?

rohan-at-sentry commented 7 months ago

@drazisil-codecov can you help out here?

drazisil-codecov commented 7 months ago

@tobiasbrunner Usually we accept lcov for C repos. Is https://github.com/codecov/cpp-11-Standard helpful?

tobiasbrunner commented 7 months ago

Thanks. That example wasn't particularly helpful, though, as it doesn't use lcov :wink: But I found this and the first C++ example uses lcov (most of the others don't) and uploads the result directly to Codecov. This also works for our project (using the GitHub action's file argument). So thanks again for the hint.