Installing docker is a prerequisite. The instructions differ depending on the environment. Docker is comprised of two parts: the daemon server which runs on Linux and accepts commands, and the client which is a Go program capable of running on MacOS, all Unix variants and Windows.
Follow the Docker install instructions.
There are development and deploy images available.
The development image is a bulky image containing a complete build toolchain.
It is well suited to hacking around and running the tests (including the
acceptance tests). To fetch this image, run ./builder.sh pull
. The image can
be run conveniently via ./builder.sh
.
Note that if you use the builder image, you should ensure that your Docker installation grants 4GB or more of RAM to containers. On some systems, the default configuration limits containers to 2GB memory usage and this can be insufficient to build/link a CockroachDB executable.
The deploy image is a downsized image containing a minimal environment for
running CockroachDB. It is based on RedHat's ubi8/ubi-minimal
image and
contains only the main CockroachDB binary, libgeos libraries, and licenses. To
fetch this image, run docker pull cockroachdb/cockroach
in the usual fashion.
To build the image yourself, use the Dockerfile in the deploy
directory after
building a release version of the binary with the development image described in
the previous section. The CockroachDB binary will be built inside of that
development container, then placed into the minimal deployment container. The
resulting image cockroachdb/cockroach
can be run via docker run
in the
usual fashion. To be more specific, the steps to do this are:
go/src/github.com/cockroachdb/cockroach $ ./build/builder.sh mkrelease linux-gnu
go/src/github.com/cockroachdb/cockroach $ cp ./cockroach-linux-2.6.32-gnu-amd64 build/deploy/cockroach
go/src/github.com/cockroachdb/cockroach $ cp ./lib.docker_amd64/libgeos_c.so ./lib.docker_amd64/libgeos.so build/deploy/
go/src/github.com/cockroachdb/cockroach $ cp -r licenses build/deploy/
go/src/github.com/cockroachdb/cockroach $ cd build/deploy && docker build -t cockroachdb/cockroach .
The list of valid/recognized targets is available in the script
build/build/mkrelease.sh
, for example amd64-linux-gnu
and
amd64-darwin
. Note that this script supports experimental targets
which may or may not work (and are not officially supported).
The cockroachdb/builder
image has a number of cross-compilers
installed for various targets. We build those cross-compilers in a
separate step prior to the actual image build, and pull in tarballs
to install them during the image build. This saves time and allows us to
use the same toolchains for the Bazel build.
Toolchains may need to be rebuilt infrequently. Follow this process to do so (if you don't need to update the toolchains, proceed to "basic process" below):
- Edit files in
build/toolchains/toolchainbuild
as desired. - Run
build/toolchains/toolchainbuild/buildtoolchains.sh
to test -- this will build the tarballs locally and place them in yourartifacts
directory. - When you're happy with the result, commit your changes, submit a pull request, and have it reviewed.
- Ask someone with permissions to run the
Build and Publish Cross Toolchains
andBuild and Publish Darwin Toolchains
build configurations in TeamCity. These will publish the new toolchains to a new subdirectory in Google cloud storage, and the build log will additionally contain the sha256 of every tarball created. - Update the URL's in
build/builder/Dockerfile
and their sha256's accordingly. Then proceed to follow the "Basic process" steps below.
- Edit
build/builder/Dockerfile
as desired. - Run
build/builder.sh init
to test -- this will build the image locally. The result ofinit
is a docker image version which you can subsequently stick into theversion
variable inside thebuilder.sh
script for testing locally. - When you're happy with the result, commit your changes, submit a pull request, and have it reviewed.
- Ask someone with permissions to run the
Build and Push new Builder Image
build configuration in TeamCity. This will build and push the new Docker image to DockerHub. - Copy the tag of the new image (which will look like
YYYYMMDD-NNNNNN
) intobuild/builder.sh
, re-commit your changes, and update the pull request. You can now merge the pull request once you've got a sign-off. - Finally, use the tag of the new image to update the
builder.dockerImage
configuration parameter in TeamCity under theCockroach
andInternal
projects.
Please copy this checklist (based on Basic Process) into the relevant commit message, with a link back to this document and perform these steps:
- Adjust the Pebble tests to run in new version.
- Adjust version in Docker image (source).
- Adjust version in the TeamCity agent image (setup script)
- Rebuild and push the Docker image (following Basic Process)
- Update
build/teamcity/internal/release/build-and-publish-patched-go/impl.sh
with the new version and adjust SHA256 sums as necessary. - Adjust
GO_VERSION
andGO_FIPS_COMMIT
for the FIPS Go toolchain (source). - Run the
Internal / Cockroach / Build / Toolchains / Publish Patched Go for Mac
build configuration in TeamCity with your latest version of the script above. Note the job depends on another jobBuild and Publish Patched Go
. That job prints out the SHA256 of all tarballs, which you will need to copy-paste intoWORKSPACE
(see below).Publish Patched Go for Mac
is an extra step that publishes the signedgo
binaries for macOS. That job also prints out the SHA256 of the Mac tarballs in particular. - Adjust
--@io_bazel_rules_go//go/toolchain:sdk_version
in .bazelrc. - Bump the version in
WORKSPACE
undergo_download_sdk
. You may need to bump rules_go. Also edit the filenames listed insdks
and update all the hashes to match what you built in the step above. - Bump the version in
WORKSPACE
undergo_download_sdk
for the FIPS version of Go (go_sdk_fips
). - Run
./dev generate bazel
to refreshdistdir_files.bzl
, thenbazel fetch @distdir//:archives
to ensure you've updated all hashes to the correct value. - Bump the version in
builder.sh
accordingly (source). - Bump the version in
go-version-check.sh
(source), unless bumping to a new patch release. - Bump the go version in
go.mod
. - Bump the default installed version of Go in
bootstrap-debian.sh
(source). - Replace other mentions of the older version of go (grep for
golang:<old_version>
andgo<old_version>
). - Update the
builder.dockerImage
parameter in the TeamCityCockroach
andInternal
projects. - Ask the Developer Infrastructure team to deploy new TeamCity agent images according to packer/README.md
You can test the new builder image in TeamCity by using the custom parameters UI (the "..." icon next to the "Run" button) to verify the image before committing the change.
Please follow the instructions above on updating the golang version, omitting the go-version-check.sh step.
The bazelbuilder
image is used exclusively for performing builds using Bazel. Only add dependencies to the image that are necessary for performing Bazel builds. (Since the Bazel build downloads most dependencies as needed, updates to the Bazel builder image should be very infrequent.) The bazelbuilder
image is published both for amd64
and arm64
platforms. You can go through the process of publishing a new Bazel build
- Edit
build/bazelbuilder/Dockerfile
as desired. - Build the image by triggering the
Build and Push Bazel Builder Image
build in TeamCity. The generated image will be published to https://hub.docker.com/r/cockroachdb/bazel. - Update
build/.bazelbuilderversion
with the new tag and commit all your changes. - Build the FIPS image by triggering the
Build and Push FIPS Bazel Builder Image
build in TeamCity. The generated image will be published to https://hub.docker.com/r/cockroachdb/bazel-fips. - Update
build/.bazelbuilderversion-fips
with the new tag and commit all your changes. - Ensure the "Bazel CI" job passes on your PR before merging.
Dependencies are managed using go mod
.
-
Familiarize yourself with our wiki page on adding or updating dependencies. In particular, you will need to go first through a non-technical step related to checking the license of the dependency. This is important and non-optional.
-
In
cockroachdb/cockroach
, switch to the local branch you plan to import the external package into -
Run
go get <dependency>@latest
. To get a specific version, rungo get <dependency>@<version|branch|sha>
. You should see changes ingo.mod
when runninggit diff
.Beware of not using
-u
(e.g.go get -u
) as the-u
flag also attempts to upgrade any indirect dependency from yours. We do not want (generally) to bundle indirect dep upgrades, which might include critical infrastructure packages like grpc, in the same PR as specific dep updates/installations. See the wiki page linked above for details.If the
go get
command still results in updates to important infrastructure dependencies besides the one you want to install, proceed as per the section "Upgrading important infrastructure dependencies" below. -
Import the dependency to a go file in
cockroachdb/cockroach
. You may use an anonymous import, e.g.import _ "golang.org/api/compute/v1"
, if you haven't written any code that references the dependency. This ensuresgo mod tidy
will not delete your dependency. Note that IDEs may bicker that these import's paths don't exist. That's ok! -
Run
go mod tidy
to ensure stale dependencies are removed. -
Run
./dev generate bazel --mirror
to regenerate DEPS.bzl with the updated Go dependency information. Note that you need engineer permissions to mirror dependencies; if you want to get the Bazel build working locally without mirroring,./dev generate bazel
will work, but you won't be able to check your changes in. (Assuming that you do have engineer permissions, you can rungcloud auth application-default login
to authenticate if you get a credentials error.) -
Run
./dev build short
to ensure your code compiles.
Follow the instructions for Installing a Dependency.
Beware of not using -u
(e.g. go get -u
) as the -u
flag also
attempts to upgrade any indirect dependency from yours. We do not
want (generally) to bundle indirect dep upgrades, which might
include critical infrastructure packages like grpc, in the same PR
as specific dep upgrades. See the wiki page linked above for details.
Note:
- You will still need to pay extra attention to the licensing step as described in the wiki page.
- If you're only importing a new package from an existing module in
go.mod
, you don't need to re-download the module, step 2 above. - If you're only updating the package version, you probably don't need to update the import statements, step 3 above.
- If the
go get
command results in updates to important infrastructure dependencies besides the one you want to install, proceed as per "Upgrading important infrastructure dependencies" below.
Sometimes a key, infrastructure-like dependency is upgraded as a side-effect of (attempting to) installing or upgrading a more lightweight dependency. See the wiki page for a list of what we consider key dependencies.
When this happens, we want to solicit more review scrutiny on this change.
To achieve this, proceed as follows:
- If coming from the sections "Installing a new dep" or "updating a dep" above, check out a branch/commit prior to the original dep install/update you wanted to perform.
- Perform the
go get ...@<version>
command only for those key dependencies you want/need to upgrade. - Proceed as per the rest of "Installing a new dependency" from step 5 onwards.
- Commit the result with a descriptive title, e.g. "deps: upgrade XXX to version YYY".
- Push this change in a PR (also with a descriptive title), then solicit a review.
When a dependency has been removed, run go mod tidy
and dev generate bazel
.