While we aim to build out-of-the-box on recent distributions, this isn't always possible and not everyone runs a recent distribution. For this reason a version-controlled toolchain is provided as a docker image.
If your workstation supports docker (without requiring sudo), you can build and run Scylla easily without setting up the build dependencies beforehand:
./tools/toolchain/dbuild ./configure.py
./tools/toolchain/dbuild ninja build/release/scylla
./tools/toolchain/dbuild ./build/release/scylla --developer-mode 1
The script dbuild
allows you to run any in that toolchain with
the working directory mounted:
./tools/toolchain/dbuild ./configure.py
./tools/toolchain/dbuild ninja
You can adjust the docker run
command by adding more flags before the
command to be executed, separating the flags and the command with --
.
This can be useful to attach more volumes (for data or ccache) and to
set environment variables:
./tools/toolchain/dbuild -v /var/cache/ccache:/var/cache/ccache -- ninja
The script also works from other directories, so if you have scylla-ccm
checked
out alongside scylla, you can write
../scylla/tools/toolchain/dbuild ./ccm ...
You will have access to both scylla and scylla-ccm in the container.
Interactive mode is also supported: running dbuild
with no arguments
will drop you into a shell, with all of the toolchain accessible.
The toolchain is stored in a file called tools/toolchain/image
. Normally,
dbuild
will fetch the toolchain automatically. If you want to access
the toolchain explicitly, pull that image:
docker pull $(<tools/toolchain/image)
If you add dependencies (to install-dependencies.sh
or
seastar/install-dependencies.sh
) you should update the toolchain.
Run the command
podman build --no-cache --pull -f tools/toolchain/Dockerfile .
and use the resulting image.
If you're a maintainer, you can tag the image and push it
using podman push
. Tags follow the format
scylladb/scylla-toolchain:fedora-29-[branch-3.0-]20181128
.
For master toolchains, the branch designation is omitted. In a branch, if there is a need to update a toolchain, the branch designation is added to the tag to avoid ambiguity.
Publishing an image is complicated since multiple architectures are supported. There are two procedures, one using emulation (can run on any x86 machine) and another using native systems, which requires access to aarch64 and s390x machines.
- Pick a new name for the image (in
tools/toolchain/image
) and commit it. The commit updating install-dependencies.sh should include the toolchain change, for atomicity. Do not push the commit tonext
yet. - Run
tools/toolchain/prepare
and wait. It requiresbuildah
andqemu-user-static
to be installed (and will complain if they are not). - Publish the image using the instructions printed by the previous step.
- Push the
next
branch that refers to the new toolchain.
- Pick a new name for the image (in
tools/toolchain/image
) and commit it. The commit updating install-dependencies.sh should include the toolchain change, for atomicity. Do not push the commit tonext
yet. - Push the commit to a personal repository/branch.
- Perform the following on an x86 and an ARM machine:
- check out the branch containing the new toolchain name
- Run
git submodule update --init --recursive
to make sure all the submodules are synchronized - Run
podman build --no-cache --pull --tag mytag-arch -f tools/toolchain/Dockerfile .
, where mytag-arch is a new, unique tag that is different for x86 and ARM. - Push the resulting images to a personal docker repository.
- Now, create a multiarch image with the following:
- Pull the two images with
podman pull
. Let's call the two tagsmytag-x86
andmytag-arm
. - Create the new toolchain manifest with
podman manifest create $(<tools/toolchain/image)
- Add each image with
podman manifest add --all $(<tools/toolchain/image) mytag-x86
andpodman manifest add --all $(<tools/toolchain/image) mytag-arm
- Push the image with
podman manifest push --all $(<tools/toolchain/image) docker://$(<tools/toolchain/image)
- Pull the two images with
- Now push the commit that updated the toolchain with
git push
.
When running sudo
inside the container fails like this:
$ tools/toolchain/dbuild /bin/bash
bash-4.4$ sudo dnf install gdb
sudo: unknown uid 1000: who are you?
You can work it around by disabling SELinux on the host before running dbuild
:
$ sudo setenforce 0