Add path context to filter options in config files #304
Conversation
By using a dedicated type for filter options it's possible include the path context for a filter. This enables (relative) filters in config files to be treated as relative to the location of the config file, rather than relative to the current working directory.
After the introduction of the FilterOption object this function is no longer needed.
| @@ -566,6 +567,7 @@ def merge_options_and_set_defaults(partial_namespaces, all_options=None): | |||
| help="Keep only gcov data files that match this filter. " | |||
| "Can be specified multiple times.", | |||
| action="append", | |||
| type=FilterOption, | |||
There was a problem hiding this comment.
This option (and gcov_excludes as well) previously didn't use the check_non_empty() function. I wasn't sure if that was deliberate or not, but in the current iteration of the code that will be a slight behavioral change. I had to modify a test case to deal with this fact.
There was a problem hiding this comment.
I'll have to think a bit more about this.
An empty filter would be a regex that always matches, and can be used to deactivate a filter. This is most important for the --filter option to deactivate filtering (the default would filter to files under --root).
But I don't think this would be useful for --gcov-filter or --gcov-exclude: it doesn't make sense to exclude all files, and accepting all files already is the default. That only leaves use cases like “deactivating filters in a configuration file” which I'm not interested in supporting at the moment.
| @@ -103,7 +103,7 @@ def test_line_threshold_100_1(capsys): | |||
| def test_filter_backslashes_are_detected(capsys): | |||
| c = capture( | |||
| capsys, | |||
| args=['--filter', r'C:\\foo\moo', '--gcov-exclude', ''], | |||
There was a problem hiding this comment.
Couldn't really figure out the necessity of this argument as it seems to have no effect or relation at all to the actual test.
There was a problem hiding this comment.
I now understand why --gcov-exclude was used here. The capture() test driver runs gcovr's main(). It actually searches for coverage data and creates a report. But this test is not about the reports, only about side effects. Setting --gcov-exclude to an empty filter ensures that no coverage data will be found, which should make the test more robust. The empty filter is the easiest way to write a filter that always matches, here: excludes all files.
Codecov Report
@@ Coverage Diff @@
## master #304 +/- ##
==========================================
+ Coverage 94.89% 94.91% +0.01%
==========================================
Files 15 15
Lines 1823 1830 +7
Branches 315 316 +1
==========================================
+ Hits 1730 1737 +7
Misses 46 46
Partials 47 47
Continue to review full report at Codecov.
|
| class FilterOption(object): | ||
| def __init__(self, regex, path_context=None): | ||
| if not regex: | ||
| raise ArgumentTypeError("filter cannot be empty") |
There was a problem hiding this comment.
Not sure if ArgumentTypeError is the most appropriate exception to use here, but I'd say it's the most straightforward to get behavior that's as similar as possible to before. I evaluated other alternatives but none really stuck. ValueError could be used, but using it will print a standardized error rather than a custom one. It will also print a traceback which the Argparse exception handling won't. If the behavior of the Argparse exception is to be preferred (mainly no traceback) a custom program exit function would need to be written. It would of course also be possible to leverage check_non_empty() to check that the value is set before passing it to the class constructor similar to how it was before, but then it would only apply to CLI args and not config file filters.
Addresses #300. From the "main" commit message:
Handling and behavior of CLI arguments is the same as before. Do note that the
check_non_empty()function ended up being unused, so I removed it (in a separate commit though, so easy to roll back).