bazelbuild / bazelbuild/continuous-integration
Embed build timestamp into Bazel last_green binaries
- Dominant language
- Python
- Stars
- 302
- Forks
- 194
- Avg merge
- 1d 19h
- Merged PRs (30d)
- 41
Description
Bazelisk users like to use `last_green` to get the latest green Bazel version near HEAD. But because we don't embed the build timestamp in these binaries, it's hard to verify how fresh the binary you're getting actually is:
```
$ USE_BAZEL_VERSION=last_green bazel version
2021/02/17 09:52:59 Using unreleased version at commit af3a556e0373830b13da6c9b1916a1b17e029298
2021/02/17 09:52:59 Downloading https://storage.googleapis.com/bazel-builds/artifacts/macos/af3a556e0373830b13da6c9b1916a1b17e029298/bazel...
Bazelisk version: development
Extracting Bazel installation...
Build target: bazel-out/darwin-opt/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Thu Jan 01 00:00:00 1970 (0)
Build timestamp: Thu Jan 01 00:00:00 1970 (0)
Build timestamp as int: 0
```
Would be cool if we could embed the timestamp there (ideally of the Git commit instead of the actual build time, to keep the binaries reproducible? 🤔)
Contributor guide
Research direction
Start with the last_green build path and the `bazel version` output shown in the issue. Determine whether the embedded value should come from the Git commit or the build time, then verify that generated last_green binaries report a nonzero timestamp while remaining reproducible.
Written by the indexing model from the issue text.
Assessment
- Domain
- build-system, ci-cd
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100