Configuring warm Bazel

Characteristics of a CI job that influence the Bazel server and its caches must be predefined, so Engflow can prepare the right runner for each job. For example, a job for x64 needs a different starting point from a arm64 job.

We support the following settings.

Bento name

The name by which you'll reference this Bento in Buildkite YAMLs or Github workflows, e.g. dev_x64. You'll then reference it in the workflow .yaml via the engflow-bento-name=dev_x64 job label.

Repo name

The URL of the repository where CI jobs will come from, e.g. github.com/MyCompany/myproject. (There should be no protocol, like https://, nor a trailing / or .git.)

CI provider

Currently: Buildkite or github

Image URL

The Docker image the CI host will use. The Buildkite/Github agent (and Git, and Bazel) will run inside of this. The image URL must include the sha256 sum of the image, e.g. my.registry/x64/ci_dev@sha256:1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef.

• All tools required for the CI host to execute the job (e.g. git, bazel, etc) must be installed into this image, except for the Buildkite/Github agents, which will be automatically staged inside this image.

• Workers in the selected pool (specified using the Pool name attribute) must be granted permission to pull this image.

Hosting location

You most likely already have some execution images that EngFlow workers use for normal RE builds. Hosting the CI images in the same registry will make sure the workers can pull them.

Pool name

The cluster pool where CI hosts will run. EngFlow will set up this pool for you as part of enabling CI runners on your cluster and provide you with the exact value for this field.

Allow snapshots

If selected (recommended), then we take a snapshot of the container (under some circumstances) and reuse it for later CI jobs.

If not selected, all jobs run cold, and will not benefit from the time savings from using warm Bazel.

Branch name

The name of the branch where snapshots can be taken from. CI jobs from other branches in the repo can also be executed, but the system won't take snapshots from such branches. We recommend setting this field to master or main branch so that snapshots are only captured for post-submit jobs, i.e. commits merged to master or main.

Advanced options

This field is for enabling experimental/advanced options. Currently, the following settings are supported:

• disk_size_gb (integer): size of the CI disk image (default: 50Gb). This setting must be synchronized with the cluster pool configuration's max input/output size.
• insert_invocation.post_agent_sleep (string): sleep after job completes, for debugging. Protobuf duration format (eg. "3600s", only unit accepted is "s")
• insert_invocation.bazel_rc_lines (object): custom Bazel flags. Contents:
• section (string): the Bazel section name (eg. common:config)
• flags (list of string): the flags
• max_test_fail_ratio (float): take snapshots even if this quantity of tests failed, between 0.0 and 1.0.
• nested_container_strategy (string): enable Docker on the CI machine. "DOCKER_SIBLING" is the only accepted value.
• network_isolation (boolean): enable network isolation

Here is an example that exercises all the fields:

{
   "disk_size_gb": 150,
   "insert_invocation": {
       "post_agent_sleep": "1200s",
       "bazel_rc_lines": [
       {
           "section": "build",
               "flags": [ "--jobs=150", "--nostamp" ]
       }
   ]
}
"max_test_fail_ratio": 0.02,
"nested_container_strategy": "DOCKER_SIBLING",
"network_isolation": true
}