Accumulate multiple uses of --instrumentation_filter cli flag

[tsiddharth]

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

[fmeum]

@c-mita

[c-mita]

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.

[tsiddharth]

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?

[rbeasley-avgo]

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.

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?

[tsiddharth]

@mzeren-vmw