Add package_metadata and instrument http_archive and other built-ins to provide supply chain information
- Dominant language
- Java
- Stars
- 25.8k
- Forks
- 4.6k
- Avg merge
- 2d 20h
- Merged PRs (30d)
- 72
Description
### Description of the feature request:
As the successor of rules_license, package_metadata should now be used in order to provide package metadata information from pulled external dependencies.
As such, http_* and other globals should add this piece of information in the generated BUILD.bazel file.
Here's the list of functions I can quickly think of, but there might be more:
* http_archive
* http_file
* http_jar
* git_override
* archive_override
* git_repository
* new_git_repository
As it would be hard for those rules alone to be able to provide all the necessary information such as the version and the right package name, we should add a new optional attribute for backward compatibility to provide a `base purl`.
Relevant PURL types:
* https://github.com/package-url/purl-spec/blob/main/types-doc/github-definition.md
* https://github.com/package-url/purl-spec/blob/main/types-doc/generic-definition.md
Those functions would add or override qualifiers to provide origin information on the pulled package such as `download_url`, `checksum`, `vcs_url` as described in the [common qualifiers](https://github.com/package-url/purl-spec/blob/main/docs/common-qualifiers.md) documentation.
This would require a purl parser and could also provide a purl builder to replace the one defined in the [supply-chain](https://github.com/bazel-contrib/supply-chain/tree/main/metadata/purl) project for modules to be able to generate one from a lib provided by Bazel core instead of an external dependency.
### Which category does this issue belong to?
Core
### What underlying problem are you trying to solve with this feature?
Provide supply chain information on the pulled packages by Bazel core
### Which operating system are you running Bazel on?
macos
### What is the output of `bazel info release`?
Not important
### 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?
There is no such other issue related to this yet
### Any other information, logs, or outputs that you want to share?
_No response_
Contributor guide
Research direction
Start by locating the http_archive, http_file, http_jar, git_override, archive_override, git_repository, and new_git_repository entry points, then review package_metadata and the referenced PURL specifications. The supply-chain purl implementation is also relevant. Done means generated BUILD.bazel files expose package metadata and origin qualifiers, with a backward-compatible base PURL and parser or builder support.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- build-system
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100