cloud-builders-community: a catalogue of Docker build steps for Cloud Build

Cloud Build is a sequence of containers, and this fills the steps

This repository contains the source code for community-contributed Docker images that you can use as build steps for Google Cloud Build. The README states in one line that these are not official Google products, and that line is the most important thing in the document.

The model it plugs into is simple enough to explain in two sentences. Google Cloud Build executes a build as a series of build steps, and each build step is run in a Docker container. So a build step that runs a tool, a linter, a package manager or a framework needs a container image with that tool installed, and this repository is where people contribute those images.

The top level directory is the catalogue, and it is long. There are builders for airflow, alcide, android, ansible, apt, awscli, az and az-kubectl for Microsoft Azure, ballerina, bandit, base-image-builder, binauthz-attestation, bookdown, boot, bq, buildah, cache, cancelot, cargo, cdxgen, cft, compodoc, composer, container-diff, cron-helper, dataflow-python and dataflow-python3, dataproc-custom-image, dep, docker-compose, docker-reuse, dokctl, earthly, envsubst, esy, fastlane, firebase, flutter, fsharp, gcloud-sops, gcluster, git-lfs, github, glide, google-closure-compiler, harness-chaos, helm, helmfile, hub, hugo, inspec, jfrog, jmeter, jsonnet, kaniko and klar, with the list continuing.

The primary language of the repository is Go, which reflects the build tooling rather than the contents. The licence is Apache 2.0, and the project is not archived, with the last push on 2026-06-11. There are no GitHub releases, which is consistent with a catalogue of independent builders rather than one versioned product.

A builder is a directory with three obligations

The contribution requirements tell you the shape of every builder, and reading them tells you what a builder is.

The first obligation is that the builder image is pushed to the builder's own project registry, for example by specifying images: ['gcr.io/$PROJECT_ID/the-tool'], and the README is explicit that the builder will not be pushed to the gcr.io/cloud-builders registry. The shared registry is where the images would live if the project hosted them, and the rule keeps the community catalogue in each contributor's own project instead. The practical effect is that a builder image is referenced as gcr.io/$PROJECT_ID/<tool> in your build config, and the $PROJECT_ID convention appears throughout the documentation.

The second obligation is a simple sanity test in the cloudbuild.yaml config that builds and pushes the image. The README says this can be as simple as invoking the tool with --help, and explains the reason: it ensures the tool is installed correctly and in the expected location within the image. That is a better reason than it first appears. A container image is a build artifact that can silently rot, because the base image moves, the install command changes, or a package disappears from a mirror. A test that runs the tool and fails loudly is what turns that rot into a visible failure at rebuild time rather than a mysterious failure in a pipeline.

The third obligation is some basic example describing how to use it, which helps new users get acquainted and helps the maintainers ensure the builder continues to work as intended. Each build step's examples directory holds one, and the README points at the packer builder's example under packer/examples/gce as the model.

Building a builder from source before you use it

The README's worked example uses the packer build step on a Linux or Mac OS X workstation, and there are four steps.

Clone the repository.

git clone https://github.com/GoogleCloudPlatform/cloud-builders-community

Then move into the directory holding the source for the image you want, in this case the packer image.

cd cloud-builders-community/packer

Then build the image with the Cloud SDK, which submits the cloudbuild.yaml in the current directory to Cloud Build itself.

gcloud builds submit --config cloudbuild.yaml .

And finally you can list what landed in the container registry.

gcloud container images list --filter packer

Before any of that, the prerequisites are a Google Cloud project, billing enabled on it, the Cloud Build API enabled, and the Cloud SDK installed and initialised. Each of those is a console step, and the billing one in particular is the one people forget, since a project without billing enabled cannot run a build at all.

There is a nice loop in the design here. The image is built by Cloud Build using the cloudbuild.yaml that lives with the builder, which means the builder builds itself with the same mechanism it is meant to serve, and the sanity test requirement means that build is also a test of the tool.

Referencing a builder in your own build config

Once the image exists, using it is a block in a Cloud Build YAML config, and the README shows the packer builder in the form you would paste.

- name: 'gcr.io/$PROJECT_ID/packer'
  args:
  - build
  - -var
  - project_id=$PROJECT_ID
  - packer.json

Three things are worth noticing in that block.

The name is the full image reference including the registry host and the project, which is a direct consequence of the rule that builder images live in the contributor's project. Your own build config therefore points at a project, and $PROJECT_ID is a substitution the build environment performs.

The args are passed straight through to the tool, so the shape of the args is the tool's own command line. Packer gets build, then -var, then a project_id assignment, then a template file. Nothing about the builder translates the interface, which is the right design: the container is a thin wrapper around the tool, and the tool's own documentation remains the documentation.

And there is no separate wiring for credentials or for the workspace, because those come from the Cloud Build environment rather than from the builder. The builder is a container that runs a command.

The practical advice is to build the image yourself, push it to your own project, and reference that, rather than reaching for somebody else's registry path. It costs one build, it gives you a version you control, and it means the image in your pipeline is one your organisation can rebuild.

What the catalogue tells you about CI practice

The list of builders is a reasonable proxy for what teams actually run inside a pipeline, and a few of the names are more interesting than the rest.

bandit is a Python security linter and inspec is a compliance testing tool, and both being here says that teams running these builders want security and policy checks to be a build step rather than a separate scan afterwards. binauthz-attestation and cdxgen fit the same family, one around authorisation and one around software bill of materials generation.

Several builders are about the container layer itself, buildah, kaniko, docker-compose and docker-reuse, which is the kind of thing you need when the build is about producing images rather than compiling code. base-image-builder and gcluster suggest the managed platform side of the same problem.

Others are ordinary toolchains, cargo for Rust, composer for PHP, flutter for mobile, ansible for configuration, helm and helmfile for Kubernetes packaging, fastlane for mobile release automation, jfrog for artifact repositories, jmeter for load testing, and github for repository operations. There are language and framework specific ones too, ballerina, fsharp, esy, hugo, bookdown, compodoc, glide, jsonnet and envsubst.

Read together, the catalogue says that a Cloud Build pipeline in practice is a set of small purpose-built containers, each one a thin wrapper around a single tool, with the effort concentrated in getting the tool into the image correctly rather than in orchestration.

Support routes, and what the absence of releases means

The support section splits the problems in two, and the split is the useful part.

For issues and feature requests against the builder images, for the usage of these build steps, or for the Cloud Build API in general, the README says to create an issue in this repository. For an issue with the Cloud Build service itself, it points to the google-cloud-dev mailing list and to the Cloud Build getting support documentation.

That division is honest about what a community project can and cannot do. Nobody in this repository can fix a Cloud Build outage, and the project says so by routing service problems elsewhere. What it can do is take a patch for a builder that no longer builds.

What it does not offer is a release cadence. There are no GitHub releases, and the repository was last pushed to on 2026-06-11. Individual builders are versioned by their own conventions, generally through the tool version their cloudbuild.yaml pins, and a builder is only as fresh as the last person who cared about it. The result is a catalogue where some entries are current and others are quietly broken, and the only reliable way to tell the difference is to build the image and run the sanity test.

That is why the contribution requirement about the sanity test matters so much. It is the mechanism that makes staleness visible. A builder whose base image has moved, or whose install command no longer resolves, fails its own test at rebuild time, and the failure lands in the pull request or in your pipeline rather than in a silent discrepancy between what the builder claims to contain and what it does. If you adopt a builder from this catalogue, build it yourself and run that test before you depend on it.

Editorial conclusion

cloud-builders-community fits a team that wants to run a tool in a Cloud Build step without maintaining its own container image, and that is willing to build and pin the image itself rather than trust a public one. It does not fit a team that needs a supported tool with a service level, since the images are community maintained with no release cadence, and it does not fit an environment where running an unmaintained base image in a privileged pipeline is acceptable risk. Verify three things before you adopt one: that the builder's cloudbuild.yaml pins the tool version you want, that the sanity test in the config actually builds and pushes the image, which tells you the container still works when it is rebuilt, and that the image you reference in your own build config is one you built and pushed to your own project registry, since the contribution rules forbid pushing builder images to the shared gcr.io/cloud-builders registry.

Frequently asked questions

Official sources

1. GoogleCloudPlatform/cloud-builders-community on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README