36c789b1fd
Also, document the fact that we cut releases only from the versioned branches, and use the correct x/net branch. Had to build this passing -skip_tests to release because the buildlet was timing out (see below), but the builders on the dashboard are green. 2018/09/28 19:14:50 linux-amd64: Start. 2018/09/28 19:14:50 linux-amd64: Creating buildlet. 2018/09/28 19:15:28 linux-amd64: Pushing source to buildlet. 2018/09/28 19:15:37 linux-amd64: Writing VERSION file. 2018/09/28 19:15:38 linux-amd64: Cleaning goroot (pre-build). 2018/09/28 19:15:38 linux-amd64: Building. 2018/09/28 19:46:20 Buildlet https://farmer.golang.org:443 failed three heartbeats; final error: timeout waiting for headers 2018/09/28 19:46:20 linux-amd64: Error: Buildlet https://farmer.golang.org:443 failed heartbeat after 10.007631241s; marking dead; err=timeout waiting for headers Change-Id: I9d982df693075f96d44aa6f163533253c8ae2914 Reviewed-on: https://go-review.googlesource.com/138555 Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Filippo Valsorda <filippo@golang.org> |
||
---|---|---|
.. | ||
build.docker | ||
build.release | ||
dockerfile.in | ||
go-wrapper | ||
README.md | ||
RELEASES | ||
VERSION |
README.md
This directory holds build scripts for unofficial, unsupported distributions of Go+BoringCrypto.
Version strings
The distribution name for a Go+BoringCrypto release has the form <GoVersion>b<BoringCryptoVersion>
,
where <GoVersion>
is the Go version the release is based on, and <BoringCryptoVersion>
is
an integer that increments each time there is a new release with different BoringCrypto bits.
The <BoringCryptoVersion>
is stored in the VERSION
file in this directory.
For example, the first release is based on Go 1.8.3 is go1.8.3b1
.
If the BoringCrypto bits are updated, the next would be go1.8.3b2
.
If, after that, Go 1.9 is released and the same BoringCrypto code added to it,
that would result in go1.9b2
. There would likely not be a go1.9b1
,
since that would indicate Go 1.9 with the older BoringCrypto code.
Releases
The build.release
script prepares a binary release and publishes it in Google Cloud Storage
at gs://go-boringcrypto/
, making it available for download at
https://go-boringcrypto.storage.googleapis.com/<FILE>
.
The script records each published release in the RELEASES
file in this directory.
The build.docker
script, which must be run after build.release
, prepares a Docker image
and publishes it on hub.docker.com in the goboring organization.
go1.8.3b1
is published as goboring/golang:1.8.3b1
.
Release process
Development is done on the dev.boringcrypto branch, which tracks master. Releases are cut from dev.boringcrypto.go1.X branches, which are BoringCrypto backported to the Go 1.X release branches. To issue new BoringCrypto releases based on Go 1.X:
-
If the BoringCrypto bits have been updated, increment the number in
VERSION
, send that change out as a CL for review, get it committed to dev.boringcrypto, and rungit sync
. -
Change to the dev.boringcrypto.go1.X branch and cherry-pick all BoringCrypto updates, including the update of the
VERSION
file. If desired, merge release-branch.go1.X into dev.boringcrypto.go1.X. Mail them out and get them committed. -
Back on the dev.boringcrypto branch, run
git fetch
,make.bash
and thenbuild.release dev.boringcrypto.go1.X
. The script will determine the base Go version and the BoringCrypto version, build a release, and upload it. -
Run
build.docker
, which will build and upload a Docker image from the latest release. -
Send out a CL with the updated
RELEASES
file and get it committed to dev.boringcrypto.
Building from Docker
A Dockerfile that starts with FROM golang:1.8.3
can switch
to FROM goboring/golang:1.8.3b2
(see goboring/golang on Docker Hub)
and should need no other modifications.
Building from Bazel
Starting from bazelbuild/rules_go
tag 0.7.1, simply download the BoringCrypto-enabled Go SDK using
go_download_sdk()
before calling go_register_toolchains()
.
For example, to use Go 1.9.3 with BoringCrypto on Linux, use the following lines
in WORKSPACE
:
load("@io_bazel_rules_go//go:def.bzl", "go_rules_dependencies", "go_download_sdk", "go_register_toolchains")
go_rules_dependencies()
go_download_sdk(
name = "go_sdk",
sdks = {
"linux_amd64": ("go1.9.3b4.linux-amd64.tar.gz", "db1997b2454a2f27669b849d2d2cafb247a55128d53da678f06cb409310d6660"),
},
urls = ["https://storage.googleapis.com/go-boringcrypto/{}"],
)
go_register_toolchains()
Note: you must not enable pure
mode, since cgo must be enabled. To
ensure that binaries are linked with BoringCrypto, you can set pure = "off"
on
all relevant go_binary
rules.
Caveat
BoringCrypto is used for a given build only in limited circumstances:
- The build must be GOOS=linux, GOARCH=amd64.
- The build must have cgo enabled.
- The android build tag must not be specified.
- The cmd_go_bootstrap build tag must not be specified.
The version string reported by runtime.Version
does not indicate that BoringCrypto
was actually used for the build. For example, linux/386 and non-cgo linux/amd64 binaries
will report a version of go1.8.3b2
but not be using BoringCrypto.
To check whether a given binary is using BoringCrypto, run go tool nm
on it and check
that it has symbols named *_Cfunc__goboringcrypto_*
.
The program rsc.io/goversion will report the
crypto implementation used by a given binary when invoked with the -crypto
flag.