Auto-locking (via facts) archive_override
- Dominant language
- Java
- Stars
- 25.8k
- Forks
- 4.6k
- Avg merge
- 2d 20h
- Merged PRs (30d)
- 72
Description
### Description of the feature request:
On first use, archive_override writes an integrity digest to MODULE.bazel.lock.
```bzl
archive_override(
module_name = "my_rules",
# save integrity to MODULE.bazel.lock
url = "https://example.com/my_rules.tar.gz"
)
```
### Which category does this issue belong to?
~_No response_~
External Dependency
### What underlying problem are you trying to solve with this feature?
This saves the headache of updating the digest manually. (Often following an essentially similar procedure.)
### Which operating system are you running Bazel on?
_No response_
### 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?
_No response_
### Any other information, logs, or outputs that you want to share?
_No response_
Contributor guide
Research direction
Start by tracing how archive_override handles its first use and how MODULE.bazel.lock is generated. Define the expected behavior for writing the integrity digest automatically, then verify it with coverage for an archive_override that has a URL but no digest.
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
- Mostly clear
- Newbie friendliness
- 25/100