bazelbuild
Accumulate multiple uses of --instrumentation_filter cli flag
Description of the feature request:
Multiple uses of —instrumentation_filter cli flag aren’t accumulated. This makes it difficult to have short hand config for a combination of coverage flags in a bazelrc file. e.g.,
build:covA --flagA --instrumentation_filter=afoo/abar,-afoo/abaz
build:covB --flagB --instrumentation_filter=bfoo/bbar,-bfoo/bbaz
build:covAB --flagA --flagB --instrumentation_filter=afoo/abar,-afoo/abaz,bfoo/bbar,-bfoo/bbaz # Filters list need to be created again
If --instrumentation_filter has the ability to accumulate multiple uses, having coverage for a combination of flags would have been as simple as,
build:covAB --config covA --config covB
Hence the feature being requested is to accumulate multiple uses of --instrumentation_filter cli flag.
Which category does this issue belong to?
Configurability
What underlying problem are you trying to solve with this feature?
Please see Description.
Which operating system are you running Bazel on?
Linux
What is the output of bazel info release?
release 7.2.1
If bazel info release returns development version or (@non-git), tell us how you built Bazel.
No response
What's the output of git remote get-url origin; git rev-parse HEAD ?
No response
Have you found anything relevant by searching the web?
No response
Any other information, logs, or outputs that you want to share?
https://bazelbuild.slack.com/archives/CA31HN1T3/p1720168700052469
I left a couple of comments on Slack which I will reproduce here.
The first is a question of how "incompatible" filters combine.
e.g:
--instrumentation_filter=foo.*,-foo/bar
and
--instrumentation_filter=foo/bar/baz.*
A couple of approaches come to mind:
- All "positive" filters are combined and all "negative" filters are combined. If a target matches the first and not the former, it's marked as "to be covered".
- Each use of the flag adds a filter to a set. If a target matches any filter, it is marked as "to be covered".
I think the second is more palatable than the first.
But to be honest, I'm not entirely comfortable with the idea.
If I add --instrumentation_filter=//foo/bar.* to a test command line, I expect the only things to be covered are things under the package "//foo/bar/...". But if a (perhaps necessary) blazerc I also have is adding things, that would no longer be true.
If I add --instrumentation_filter=//foo/bar.* to a test command line, I expect the only things to be covered are things under the package "//foo/bar/...". But if a (perhaps necessary) blazerc I also have is adding things, that would no longer be true.
I think/guess that if semantics of --instrumentation_filter cli option are changed to accumulate its multiple uses, then above should perhaps not be a problem because the user would be aware that bazelrc supplied --instrumentation_filter cli would be accumulated with that set explicitly on the bazel command line. Or is there a gap in my understanding?
I left a couple of comments on Slack which I will reproduce here.
The first is a question of how "incompatible" filters combine.
e.g:
--instrumentation_filter=foo.*,-foo/barand--instrumentation_filter=foo/bar/baz.*A couple of approaches come to mind:
- All "positive" filters are combined and all "negative" filters are combined. If a target matches the first and not the former, it's marked as "to be covered".
- Each use of the flag adds a filter to a set. If a target matches any filter, it is marked as "to be covered".
I think the second is more palatable than the first.
But to be honest, I'm not entirely comfortable with the idea.
If I add
--instrumentation_filter=//foo/bar.*to a test command line, I expect the only things to be covered are things under the package "//foo/bar/...". But if a (perhaps necessary) blazerc I also have is adding things, that would no longer be true.
What about considering + as a special operator that effectively translates to "append this to the filter list"? This would be somewhat similar to the handling of --output_groups.
--instrumentation_filter=//baz/.* --instrumentation_filter=//foo/bar/.*evaluates to--instrumentation_filter=//foo/bar/.*.--instrumentation_filter=//baz/.* --instrumentation_filter=+//foo/bar/.*evaluates to--instrumetnation_filter=//baz/.*,//foo/bar/.*.
@tsiddharth What's your take on +? Is that something you'd want to try prototyping internally to see how it feels?
