bazelbuild / bazelbuild/bazelisk
FR: Cache Bazel version history
- Dominant language
- Go
- Stars
- 2.7k
- Forks
- 424
- PR merge metrics
- No merged PRs in 30d
Description
During working on #438 we found out that Bazelisk spends too much time on retrieving the Bazel version history (a process that happens every time we use a relative Bazel version identifier).
The GitHub repo implementation already caches the history for one hour (https://github.com/bazelbuild/bazelisk/blob/master/httputil/httputil.go#L241). We should implement something similar for GCS.
Contributor guide
Research direction
Start by reading the existing one-hour GitHub history cache in httputil/httputil.go, then trace the corresponding GCS version-history retrieval path. The work is done when GCS history retrieval has equivalent one-hour caching and the relevant behavior is covered by tests.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, google-cloud
- Domain
- cloud, performance
- Issue type
- Feature
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100