The prune logic would prune multiple times because one prune could cause more things to be capable of pruning and change the logic. This was done through a recursive invocation. Since go doesn't have support for function tail calls, this would result in a new stack entry for each loop. This unrolls the logic so the prune function is invoked iteratively rather than recursively. `prune` and `pruneOnce` have also had their names swapped. In general, `pruneOnce` implies that it runs a single prune while `prune` sounds like the top level function. The current code had this reversed and `pruneOnce` would call `prune` and `prune` would call itself recursively. I've also updated a section in the controller that invoked prune on each worker. In older versions of Go, the current version was correct because those versions of Go would reuse the location for each loop which would cause goroutines to all reference the same worker instead of different workers. Recent versions of Go have changed the behavior so this is no longer needed. Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
Buildkit Docker Compose
The hack/compose script provides a convenient development environment for building and testing buildkit with some
useful supporting services and configuration using docker compose to assemble the environment.
This configuration is not meant for production deployments.
Usage
The primary way to use the script is as a substitute to docker compose.
$ hack/compose up -d
All arguments to this script will be forwarded to docker compose.
This will use the moby/buildkit:local image to create a buildkit container.
The image can be either built with make images or the --build flag can be used.
$ hack/compose up -d --build
To access the newly created development buildkit, use either:
$ buildctl --addr docker-container://buildkit-dev ...
or alternatively configure a new builder with buildx.
$ docker buildx create \
--bootstrap \
--name dev \
--driver remote \
docker-container://buildkit-dev
Extending Configuration
The compose definition can be extended by using -f $COMPOSE_FILE to extend the configuration.
These files are in the extensions folder.
As an example, an extension can be used for aiding with buildx metrics development:
$ hack/compose -f hack/composefiles/extensions/buildx.yaml up -d --build
This will modify the otel-collector configuration to emit buildx metrics to the debug exporter.
Some of the files in this directory can be combined and some conflict with each other. In particular,
configurations that modify the otel-collector probably conflict with each other.
Running the debugger
The debugger is exposed for the local buildkit when --build is used to build the local image.
This can be accessed using delve or any GUI client that uses delve (such as JetBrains GoLand).
$ dlv connect localhost:5000
More detailed documentation on remote debugging is here.
OpenTelemetry
OpenTelemetry is automatically configured for traces. These can be visualized through Jaeger.
Traces
Traces are sent to Jaeger.
Traces that happen in buildctl and buildx are automatically sent to buildkit which forwards them to Jaeger.