Get urls/branch/paths from environment variables for git_override, archive_override, local_path_override
- Dominant language
- Java
- Stars
- 25.8k
- Forks
- 4.6k
- Avg merge
- 2d 20h
- Merged PRs (30d)
- 72
Description
### Description of the feature request:
Allow the module override functions (git_override, archive_override, local_path_override) to get their key value (e.g. commit) from an environment variable. This is to allow easily customizing module overrides without having
to modify MODULE.bazel.
So one would do e.g.
```
git_override(
name = "rules_foo",
branch = "${RULES_FOO_COMMIT:-deadbeef}",
)
```
For repo rules, this is mostly already possible by creating custom repo rules. There isn't a equivalent for module overrides, though.
### Which category does this issue belong to?
_No response_
### What underlying problem are you trying to solve with this feature?
The general problem to solve is when you want to follow the bleeding edge version of code. For example, say you want to use the latest (or near latest) code from a project using git_override.
Using branch=master somewhat works, but has two downsides:
1. You have near-zero control over what commit is used
2. You have very little visibility into what commit was used
3. Subsequent invocations may use a different commit, depending on the bazel cache state, exacerbating non-determinism.
While an automated system could modify MODULE.bazel, that imposes a large engineering cost in various ways. Operating such a system is a decent amount of overhead. More importantly, if one wanted to track the bleeding edge of multiple dependencies, it means the commit rate of changes to MODULE.bazel is the sum of all those dependencies.
Comparatively, it is trivial to, for example, have a GHA job runs some shell to compute a commit (e.g. latest commit mod hour), persist that somewhere, then run a second job with that commit in an environment variable. This then yields relatively stable and deterministic behavior while still tracking near head.
### Which operating system are you running Bazel on?
linux
### What is the output of `bazel info release`?
_No response_
### 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?
Didn't find any.
### Any other information, logs, or outputs that you want to share?
_No response_
Contributor guide
Research direction
Start at the git_override, archive_override, and local_path_override entry points and the MODULE.bazel usage shown; determine how environment-derived values should be handled. Add coverage for environment values supplying branch, archive, and local-path inputs; done means each override supports this without editing MODULE.bazel while retaining predictable selected values.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- git
- Domain
- build-system
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 52/100