bazelbuild / bazelbuild/continuous-integration

Embed build timestamp into Bazel last_green binaries

Open
#1,108 0 comments 0 reactions 0 assignees View on GitHub
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

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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.