Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
33516: build,Makefile: break up the release process into two phases r=bdarnell a=danhhz
I need the bound the time I can spend babysitting the next release if
anything goes wrong, so this is done in a purely additive manner which,
in the worst case, will allow falling back to the previous release
process. Once we're happy with the new one, we can clean up the old code
and scripts.
The first phase is to build provisional binaries. These are exactly the
bits we intend to ship as whatever version we're releasing. The
provisional SHA is marked in git by a tag with the form
`provisional_yyyymmddhhss_<semver>`. The various binaries (a combination
of platform, fully static vs not, race vs not) are uploaded to their
final places in s3, but nothing points at them.
At this point, the release coordinator will stage these binaries on the
long running clusters for verification. A followup PR will also allow
them to be used for a run of the nightly and weekly roachtests.
If any issues are found, a new SHA is selected, a new provisional tag is
pushed for it, binaries are built again, and verification is resumed.
Once we have provisional binaries that we're happy with, they're
blessed, which is the second phase. This makes and uploads the source
archive artifact. If the release is the latest stable release, it also
updates the various latest pointers.
The continuous publication of binaries for every green master build is
still supported but currently a bit of a hack. Ideally, the teamcity
build for it would work by releasing the provisional binaries and
immediately blessing them. However, the latest pointers work differently
between the two, so for now, this entire process is left inside the
provisional binaries step and blessing is disallowed for non-releases.
Perhaps we can unify the behaviors a bit and clean this up at some
point. The standalone workload binary is no longer continuously
published, since it's now built into the cockroach binary.
To pull all of this off, a small bit of functionality had to be added to
the Makefile. The version that a binary self reports is usually
determined automatically based on the "closest" git tag of whatever
checkout built it. We don't want the provisional tags to be considered
in this, so when we build the provisional binary, we need to override
the version. A BUILDINFO_TAG override is added for this to the various
ways to make a binary `make {mkrelease,build,...}` as well as `make
archive`.
As far as I can tell, everything is uploaded to the same place and with
the same folder and binary names as before, _except_ the folder inside
the artifact for the latest binary is now `cockroach_<semver>_<suffix`
instead of `cockroach_latest_<suffix>`. This should be fine, since both
`crl-stage-binaries` and `roachprod stage untar it with
`--strip-components 1`. (In fact, I think finally doing the TODO to
always make latest a redirect may be as simple as adding the `-L` flags
to curl in those two places.)
Release note: None
Co-authored-by: Daniel Harrison <daniel.harrison@gmail.com>- Loading branch information
