Bazel Docker Image

Debian multi-platform Bazel Docker images with:

platforms: amd64, arm64
reproducible-containers/repro-sources-list.sh for Reproducible Builds
non-root user (so e.g. rules_python works without ignore_root_user_error = True)
Bazelisk with Bazel cached for the non-root user
ca-certificates for SSL cert verification
git for Bazel's git_repository, git_override, etc.
.bashrc with bash and Bazel autocompletion

Building and pushing the images

The build-docker-images Github Actions workflow builds the images, pushes them to the GHCR registry and links them with this repo.

Image "flavors"

The workflow builds different "flavors" (types of images). Each "flavor" corresponds with a Docker named build stage (... AS <NAME>) in the Dockerfile.

Triggers

The workflow is triggered when a push to the main or testing branch contains changes to the Dockerfile. It can also be triggered manually via the Actions web UI, the GH REST API or the GH CLI web UI, the GH REST API or the GH CLI tool, e.g.:

gh workflow run build-docker-images

`push`

When triggered by a push event the action will:

Determine which Dockerfiles are affected.
For those Dockerfiles, determine the build targets in it.
Filter the build targets:
- first with RE_TARGET_INCLUDE, which defaults to empty so it will match all build targets.
- then with RE_TARGET_EXCLUDE: set by default to remove some of the build targets (those marked with \-nobuild).
Finally, it will spawn a docker/build-push-action job for each of the build targets. For every image built it will push to the registry three image tags:
- a sha tag with the short hash of the commit that triggered the push
- a date tag with the current date in ISO format (YYYYMMDD)
- a latest tag

`workflow_dispatch` (manual)

When triggered manually (workflow_dispatch event) the workflow will default to "running in test mode": it will follow the same steps as a push run but with different default values (see workflow_dispatch.inputs):

RE_TARGET_INCLUDE set to ^debian$ and
RE_TARGET_EXCLUDE set to the same pattern as in the push event

This effectively limits the build targets to only the "base" debian image.

The "test run" also limits the PLATFORMS to linux/amd64, to further reduce the cost and time of a test run.

Finally, it will build that target but it won't tag latest or push any of the image tags to the registry.

This "test mode" behavior can be changed by setting the workflow_dispatch.inputs variables: RE_TARGET_EXCLUDE, RE_TARGET_INCLUDE, PLATFORMS, TAG_DATE, TAG_LATEST and PUSH, e.g.:

gh workflow run build-ci-docker-images \
  -f RE_TARGET_INCLUDE=ubuntu2404 -f TAG_DATE=20241101

jjmaestro/bzldocker