bazelbuild / bazelbuild/bazel

Get urls/branch/paths from environment variables for git_override, archive_override, local_path_override

Open
#31,067 2 comments 0 reactions 0 assignees View on GitHub
team-ExternalDeps type: feature request untriaged
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.