Merge pull request #62227 from ixdy/document-source-date-epoch

Automatic merge from submit-queue. If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>.

Add documentation around build reproducibility and SOURCE_DATE_EPOCH

**What this PR does / why we need it**: makes some of our notes about reproducibility a bit more discoverable.

**Release note**:

```release-note
NONE
```

/assign @BenTheElder
pull/8/head
Kubernetes Submit Queue 2018-04-06 18:21:43 -07:00 committed by GitHub
commit 9939f709e4
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 19 additions and 0 deletions

View File

@ -107,4 +107,23 @@ In addition, there are some other tar files that are created:
When building final release tars, they are first staged into `_output/release-stage` before being tar'd up and put into `_output/release-tars`.
## Reproducibility
`make release`, its variant `make quick-release`, and Bazel all provide a
hermetic build environment which should provide some level of reproducibility
for builds. `make` itself is **not** hermetic.
The Kubernetes build environment supports the [`SOURCE_DATE_EPOCH` environment
variable](https://reproducible-builds.org/specs/source-date-epoch/) specified by
the Reproducible Builds project, which can be set to a UNIX epoch timestamp.
This will be used for the build timestamps embedded in compiled Go binaries,
and maybe someday also Docker images.
One reasonable setting for this variable is to use the commit timestamp from the
tip of the tree being built; this is what the Kubernetes CI system uses. For
example, you could use the following one-liner:
```bash
SOURCE_DATE_EPOCH=$(git show -s --format=format:%ct HEAD)
```
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/build/README.md?pixel)]()