bazelbuild
Change `build_tag_filters` and `test_tag_filters` options to accumulate uses
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
I'm running into this issue right now too. It would be great if these flags accumulated.
In our .bazelrc, we specify test --test_tag_filters=-blacklist to exclude blacklisted tests by default. But if somebody wants to run specifically tagged tests, it will also run blacklisted tests unless they remember to add -blacklist manually to their list of tags. It would be a much nicer interface if they had to intentionally add blacklist instead to re-enable that tag.
Any progress on this? Or hints for me contributing a PR? This is making tags not very useful at all.
@dslomov Can you help triage this issue? TensorFlow was hit by similar problem recently.
I think this makes sense. But given the change in semantics, maybe it'd be worth adding this feature as a new --test_tag_filter (singular) flag that takes just one override (like --action_env does for example) and then migrate people to the new flag?
And it'd be worth assessing if we have other similar flags in Bazel so that we can address all of them in one go, with the same syntax.
Hi there! We're doing a clean up of old issues and will be closing this one. Please reopen if you’d like to discuss anything further. We’ll respond as soon as we have the bandwidth/resources to do so.
This very much is still an issue. It basically makes the whole tag_filters unusable in a larger codebase.
I would very much appreciate any improvements here.
I think this would be a nice improvement for Bazel. However, we don't have capacity to work on this immediately. If anyone from the community is willing to send a PR, we'll be happy to review it!
Ditto, I'd love to see a more thorough document describe the different ways people want to use it. For example in my use case:
given multiple test targets bazel test :all where one has tags=['a'], and the other has tags=['b'] if I add --test_tag_filters=-a, I get the 'b' test. If I say --test_tag_filters=b, I get the 'b' test.
It appears that --test_tag_filters=+a is the same as =a
However! in our checked-in $worktree_buildroot_top_level_dir_thingie/.bazelrc someone added test --test_tag_filters=-broken but how can I merely "add" those back in? If given the original example I had essentially concatenated on the command line bazel test :all --test_tag_filters=-b --test_tag_filters=+b I don't get both a and b, I only get b, because the + is essentially ignored.
'+' is not mentioned in the documentation (note, i'm on bazel 6.5.0, I haven't checked source or other versions). In my case, I'd minimally like to change the + to be an additive operation instead of an assignment operation. It could enable a use case like --test_tag_filters=a --test_tag_filters=+some --test_tag_filters=+more (because these flags might come from different/multiple .bazelrc's)
In the general case originally proposed here, "and" and "or" operators would likely be a better option to be more explicit.
See also https://github.com/bazelbuild/bazel/issues/3705 which suggests
expr = IDENT | '(' expr ')' | expr AND expr | expr OR expr | NOT expr
+1, currently dealing with many hours of wasted effort trying to understand exactly why certain test_tag_filters are being applied in a large codebase.
While we are listing our wishes, it would be nice if there was some way to get the list of tests to be run after test_tag_filters have been applied. From our experience, this is proving to be tricky (impossible?) to do.
