Using tags= to control bazel behaviour is confusing
- Dominant language
- Java
- Stars
- 25.8k
- Forks
- 4.6k
- Avg merge
- 2d 20h
- Merged PRs (30d)
- 72
Description
### Description of the bug:
Today, tags=[] has two disjoint purposes:
1- user created tags to let us filter targets (i.e. --test_tag_filters= )
2- bazel commands such as "manual" or "exclusive" as per https://bazel.build/reference/be/common-definitions#common.tags
I realize this has existed for a long time, but this dual use confuses users.
local=True|False is the only one that ever achieved escape velocity into its own attribute, although tags=[local] hasn't yet been deprecated, so its escape / promotion is not complete.
I think the remaining tags should be moved out from tags=[] to their own top level attributes.
A vague proposal (i.e. I spent only 30s thinking these up; feel free to ignore the rest of this bug and come up with your own scheme, because naming is hard!):
* for sandbox related "tags", transition to sandbox=["local", "requires-network", "no-cache", ...]
* for tests, transition to execution_behaviour=["manual", "exclusive", ...]
* or, both sets of strings just get moved to execution=[]
I have no strong opinion about test suites inserting test sizes into tags (i.e. "small" through "enormous")
Yes, this means "local" will now exist in 3 places (until it's removed from tags=[] ) but this seems like the right way to go; preserve the strings nature, just relocate where they're defined.
### Which category does this issue belong to?
Core
### What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
_No response_
### Which operating system are you running Bazel on?
Linux (Ubuntu 20)
### What is the output of `bazel info release`?
release 6.5.0
### 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` ?
```text
```
### If this is a regression, please try to identify the Bazel commit where the bug was introduced with bazelisk --bisect.
_No response_
### Have you found anything relevant by searching the web?
_No response_
### Any other information, logs, or outputs that you want to share?
tags=[], abused like this since the beginning of Blaze + TAP
Contributor guide
Research direction
Start with the common.tags documentation linked in the issue and trace how Bazel currently defines and consumes tags for filtering, sandbox behavior, and test execution. The issue does not name implementation files or tests; work is complete only after a concrete attribute design, migration or deprecation plan, and agreement on the affected tag values are established.
Written by the indexing model from the issue text.
Assessment
- Domain
- build-system
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100