Bug - invalid run/call of gcovr by action when the "root" parameter is specified

[niwciu]

The bug is strictly related to how gcovr should be called regarding its documentation. You can find their information that the search path for coverage files is set by default to -root.

gcovr doc

In this case, when using action without specifying "root" and "working-directory" or specifying just the "working-directory", gcovr is run with no arguments, so just like using the command "gcovr" on the local machine in the folder where you currently are. In the second case, the action is changing the working directory before running gcovr. In general, it leads to the same use case.

If you specify "path" and "working directory" it will lead to the scenario where the action will change the working directory to requested and then run gcovr with additional argument --root equal to the "root" parameter. Having in mind what's written in gcovr specification, this leads to a scenario that gcovr is not searching coverage files in the working directory but under the "path" directory that was passed as --root argument. This in turn leads to incorrect check results.
The same issue is related to the scenario where the action is used only with the "root" parameter.

Proposed solutions:

1. the fastest but not the most elegant - add a dot (".") in gcovr.ts line 58, - this way gcovr will always search for coverage files starting in the directory where action was called.

2. more in line with gcovr specification - instead of changing the working directory before running the gcovr add the working directory as a "search_paths"

[latk]

I'm one of the gcovr maintainers, but am unaffiliated with the gcovr-action in this repository.

You're correct that changing the working directory can lead to weird situations, because the search_paths arguments default to the --root directory.

There can be a difference between two calls

gcovr --root foo search_path

cd search_path && gcovr --root ../foo .

Due to the heuristics used by gcovr, these can produce different results. In many cases, changing the current working directory is strictly necessary. E.g. it has been reported that in many CMake builds, cd build && gcovr --root ../src . is the appropriate recipe.

So the proposed solution (1) (always adding a . search path) is probably much more helpful in most cases, but ideally the gcovr-action would add another search-paths option (with a default of ["."]).

[niwciu]

Hi. Thanks for confirming my doubts. Indeed, the "working-directory" could be separated from the search-paths. Before you wrote it I was thinking a bit wider about the usage "working-directory" parameter in this action. Probably too wide. Taking everything into consideration, in my opinion adding a search path with default value "." is the best option.

[threeal]

Hi @niwciu, thank you for raising this issue.

In my opinion, regardless of how Gcovr should be called, any GitHub action that calls a program should have a working-directory input to accommodate users who want to call the program in a specific location. This aligns with how GitHub Actions is designed, as there's no way to change the working directory unless the action itself does so.

Secondly, this action primarily abstracts Gcovr command line arguments into action inputs. Most action inputs are simply converted into the corresponding Gcovr arguments. For example, if Gcovr is expected to be called as gcovr --root path --fail-under-line 100, this action accommodates that by allowing users to use the following action inputs:

- uses: threeal/gcovr-action@v1.1.0
  with:
    root: path
    fail-under-line: 100

Regarding the search-paths input, instead of making . the default, I think it's preferable to call the action like this:

- uses: threeal/gcovr-action@v1.1.0
  with:
    root: path .

However, the root input currently passes the input as a single argument, so we might need to change it to accommodate multiple arguments.

Alternatively, we could introduce a search-paths argument:

- uses: threeal/gcovr-action@v1.1.0
  with:
    search-paths: .