Default value for `instrumentation_filter` will change when using on instrumentation test targets
- Dominant language
- Java
- Stars
- 25.8k
- Forks
- 4.6k
- Avg merge
- 2d 20h
- Merged PRs (30d)
- 72
Description
### Description of the problem / feature request:
The behavior of `instrumentation_filter` doesn't match the [documentation](https://docs.bazel.build/versions/main/command-line-reference.html#flag--instrumentation_filter)'s description: `default: "-/javatests[/:],-/test/java[/:]"`
For example, here is the result of offline instrumentation test result of different commands with options:
```
bazel coverage app → offline instrumentation works
bazel coverage app //unit-test-target → only unit test lib got offline instrumentation
bazel coverage app-instrumentation-test → offline instrumentation doesn't work
bazel build app-instrumentation-test --collect_code_coverage → offline instrumentation works
bazel coverage app-instrumentation-test --collect_code_coverage → offline instrumentation doesn't work
```
As you can see, the behavior is very inconsistent and the root cause is that the default value of `instrumentation_filter` will be changed to match the target itself when we run `test` command on an instrumentation test target, meaning none of the dependency will got instrumented.
Example, say `//app` depends on `//battery`, when we run `bazel coverage app-instrumentation-test`, the default `instrumentation_filter` for `//battery` will be "-/battery[/:]" and the same applies to all other libraries
### Expected behavior
Either update the documentation, or keep default value of `instrumentation_filter` unchanged everywhere.
Contributor guide
Research direction
Start with the instrumentation_filter command-line reference and reproduce the listed bazel coverage and build commands using the app, battery, and instrumentation-test targets described in the issue. Compare the effective filter for dependencies such as //battery; done means either the documented default is applied consistently or the documentation accurately describes the behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- build-system, testing-qa
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 30/100