Support build_runfile_manifests switching
- Dominant language
- Java
- Stars
- 25.8k
- Forks
- 4.6k
- Avg merge
- 2d 18h
- Merged PRs (30d)
- 75
Description
### Description of the feature request:
The --nobuild_runfile_manifests flag is really useful when you have it on and it stays on, but the restriction of it not working on run and local test actions makes it borderline unusable in practice in a meaningfully large codebase.
There are ways to swap the flag based on the action, but this swapping drops the analysis cache which is very painful.
I can see 2 different paths forward to allowing this flag to be used more broadly without the major downside:
* Update the flag to not drop the analysis cache when switching
* Allow --nobuild_runfile_manifests (or a similar new flag) that dynamically writes out the run file manifests for actions that need it
### Which category does this issue belong to?
Local Execution
### What underlying problem are you trying to solve with this feature?
Only have --nobuild_runfile_manifests apply to portions of my codebase / commands
### Which operating system are you running Bazel on?
Linux
### What is the output of `bazel info release`?
release 9.2.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
```
### Have you found anything relevant by searching the web?
Relevant issues:
#4177
#6627
#9248
### Any other information, logs, or outputs that you want to share?
_No response_
Contributor guide
Research direction
Start by reviewing the current behavior of --nobuild_runfile_manifests for run and local test actions, then read related issues #4177, #6627, and #9248. Done means selecting and implementing a defined approach that supports partial or dynamic manifest generation without dropping the analysis cache, with the behavior validated for the affected actions.
Written by the indexing model from the issue text.
Assessment
- Domain
- build-system, cli
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100