Skip to main content

Make targets

The Makefile in the repository root is the single entry point for building images, running the checks for every component, and starting the stack. Run make help to print the annotated targets.

Run all commands from the repository root. Pass variables on the command line, for example make generation FLAVOR=gpu.

Variables​

VariableDefaultDescription
FLAVORcpuWhich generation to build: cpu or gpu. Every artifact path and image name includes the flavor, so the two flavors do not overwrite each other. See flavors and catalogues.
TAGUTC timestamp (YYYYMMDD-HHMMSS)Tag added to the worker image, alongside latest.
ANALYZE_EXCLUDEgoogleSpace-separated packages make analyze skips, with everything under them.
ROOTFS_REQUIREMENTSpipeline/rootfs-requirements.txt (empty)File of distribution names, relative to the repository root, that the root filesystem installs on top of ROOTFS_BASE_IMAGE. make rootfs-requirements writes one from a plan.
ROOTFS_REQUIREMENTS_STRICTfalseWhen true, the image build fails if a listed distribution does not install. Otherwise the failures are listed in /etc/readie-rootfs-skipped.txt in the root filesystem.
ROOTFS_PYTHONPATH/usr/local/lib/python3.12/dist-packagesWhere the root filesystem's Python keeps packages. The python:3.12 images use /usr/local/lib/python3.12/site-packages.
ROOTFS_APT_PACKAGESemptyDebian or Ubuntu packages, comma separated, that the root filesystem installs before the distributions. Use it for the system libraries that wheels load and the base image lacks.
ROOTFS_EXTRA_INDEX_URLemptyExtra package indexes for pins that the default one lacks, comma separated when there are several. With any set, the install looks at every index for the best match, so each listed index can supply any package name. Set it empty for a base whose pins are all on PyPI.
PLAN_DIRpipeline/plan/<flavor>Where make rootfs-requirements writes the plan and the list.
REUSE_PLAN_DIRemptyA plan directory from an earlier make rootfs-requirements, relative to the repository root. When set, make capture mounts it into the container and reuses that plan instead of planning again. When empty, capture plans inside the container.
READIE_PLANNERgreedyCheckpoint planner: greedy or fixed.
READIE_MAX_CHECKPOINTS15Most checkpoints a plan may produce.
READIE_SIZE_BUDGET_MB2048.0Total size budget for checkpoints, in MB.
READIE_ALPHAset in the MakefileSize-versus-time weight. See cost model.

The four READIE_* planner values are set with := in the Makefile. A value passed on the command line takes precedence, for example make capture READIE_ALPHA=<seconds-per-mb>. A value that is only exported in the shell does not.

These values can differ from the pipeline's own defaults (for example 8 checkpoints), because make capture always passes its own values to the pipeline. See Configuration reference.

The following names are derived from FLAVOR:

NameValue
ARTIFACTS_DIRpipeline/out/<flavor>
CATALOGUE_DIRcatalogues
PIPELINE_IMAGEreadie-pipeline-<flavor>:latest
ANALYZER_IMAGEreadie-pipeline-analyzer-<flavor>:latest
WORKER_BASEreadie-worker-base-<flavor>:latest
WORKER_IMAGEreadie-worker-<flavor>
ROOTFS_BASE_IMAGEgcr.io/kaggle-images/python for cpu, gcr.io/kaggle-gpu-images/python for gpu

Everyday targets​

TargetWhat it does
allGenerate protos, then lint, type-check and test everything.
installSync every Python virtual environment from its lockfile and download Go modules.
lintLint every component, and lint and format-check the protos.
typeType-check the four Python components. The Go worker has no type target.
testTest every component. The worker tests run with the race detector. Most tests use fakes and run anywhere.
helpList the annotated targets.

The command make lint type test is the full check that CI repeats.

Per-component targets​

A pattern rule forwards <component>-<verb> to that component's own Makefile. The components are router, pkg, executor, pipeline and worker.

make worker-test # same as: make -C worker test
make router-lint
make pkg-type
make pipeline-test
make pipeline-corpus FLAVOR=gpu ARGS="--total 500" # append 500 new items to the flavor's corpus

pipeline-corpus forwards to the pipeline's own corpus target. It needs the corpus extra and the credentials listed in Configuration reference. make generation does not build a corpus.

See Repo map for the contents of each component.

Proto targets​

Generated code is committed. After editing a .proto file, run make protos and commit the result. See Changing protos.

TargetWhat it does
protosRegenerate all gRPC stubs (Python and Go).
protos-pythonRegenerate the router and client Python stubs.
protos-goRegenerate the worker's Go stubs.
protos-lintLint and format-check the protos with buf.
protos-fmtFormat the protos in place.
protos-breakingCheck the protos for breaking changes against main.
clean-protosRemove the generated Python stubs.

Checkpoint build targets​

These targets build the images that hold checkpoints and require Docker. Targets with yes or amd64 only in the gVisor column work only on an amd64 Linux host with real gVisor, and do not work on Apple Silicon or in CI. For the procedure, see Build checkpoints.

TargetgVisorWhat it does
rootfs-requirementsnoPlan on the host with plan --no-spec and write the distributions the plan needs to $(PLAN_DIR)/rootfs-requirements.txt. Needs uv, and no Docker or gVisor. See Build checkpoints.
pipeline-imagenoBuild the offline pipeline image.
analyzer-imageamd64 onlyBuild the analyzer image (the pipeline on the base image itself).
analyzeamd64 onlyMeasure every package the flavor's base image installs. Writes pipeline/data/metadata/<flavor>.json, including the version of each distribution and the name of the base image. Runs with no network.
captureyesPlan and capture checkpoints into pipeline/out/<flavor>. Runs a privileged container. Fails if no manifest is produced, then copies the catalogue to catalogues/<flavor>.json.
worker-basenoBuild the base image the worker runs on: gVisor and the root filesystem. It does not contain the checkpoints and does not need a capture first.
worker-imagenoBuild the worker image on top of the base. This is a Go build and takes seconds. Builds the base first if it is missing.
generationyesRun capture, worker-base and worker-image in order. docker compose then mounts pipeline/out/<flavor>/checkpoints and manifest.json into the worker.
clean-artifactsnoDelete captured checkpoints and the manifest for the flavor.

To redeploy a worker code change without capturing again, run make worker-image alone, then recreate the container.

Run targets​

These targets wrap Docker Compose. See Run the stack locally and Deploy with TLS.

TargetWhat it does
run-localStart NGINX, the router and a worker with docker-compose.yml plus docker-compose.local.yml (plaintext on port 50051).
run-prodSame, with docker-compose.prod.yml (TLS on port 443).
shutdownStop the containers with docker compose down --remove-orphans.

Documentation targets​

The documentation site has its own targets in the root Makefile:

TargetWhat it does
docs-installInstall the documentation site's npm dependencies (npm ci). Needs Node 20 or newer.
docs-toolsInstall protoc-gen-doc, the generator behind the protobuf reference page.
docs-protosRegenerate the protobuf reference page (architecture/protos) from protos/*.proto. Needs protoc and protoc-gen-doc on your PATH.
docs-buildBuild the static site. Fails on any broken link or anchor.
docs-startRun the site with live reload.
docs-serveBuild the site, then serve the result locally.

See also​