Change `build_tag_filters` and `test_tag_filters` options to accumulate uses
- Dominant language
- Java
- Stars
- 25.8k
- Forks
- 4.6k
- Avg merge
- 2d 20h
- Merged PRs (30d)
- 72
Description
### Description of the feature request:
Change `--*_tag_filters` options to accumulate multiple uses, or provide some alternative mechanism for achieving the same thing.
Many of bazel's command line rules accumulate multiple uses. This is very useful for providing default configuration in a repository `.bazelrc` which users can then build upon or modify in their own `bazelrc` files and with command-line syntax. Currently, these tag filter rules don't allow for the same sort of use.
### Feature requests: what underlying problem are you trying to solve with this feature?
For example, we have a `Makefile` rule that runs flake8 linting test before all other tests (because flake8 fails quickly if it fails), which looks something like this:
```
test:
bazel test //... --test_tag_filters=+flake8
bazel test //... --test_tag_filters=-flake8
```
This works great until you start adding other `--test_tag_filters` to your `.bazelrc` (either a default config one or your user one). These invocations totally ignore those options. It would be very nice if they simply accumulated, like `--action_env`, for example.
Perhaps the extra syntax `--build_tag_filters=^tag1,+tag2,-tag3` could be used where `^tag1` means "ignore any previous mentions of `tag` in this list". This would enable `.bazelrc` filter lists to include `-tag1` (or `+tag1`), while letting the command line invocation override that.
### What's the output of `bazel info release`?
`release 0.22.0`
Contributor guide
Research direction
Start by tracing how --build_tag_filters and --test_tag_filters are parsed and applied across bazelrc and command-line invocations. Compare their behavior with accumulating options such as --action_env, then define and test whether repeated filters accumulate and how any override syntax should work, including the documented Makefile example.
Written by the indexing model from the issue text.
Assessment
- Domain
- build-system, cli
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100