I’m Christian Roggia, a Backend Engineer at Engel & Völkers Technology. At our company choosing the best tools and platforms is an ever-changing challenge and we are encouraged to experiment and share with other engineers the results we have been able to achieve.In this article we will analyze two tools I’ve been experimenting with for months and I will share my experience, and why we decided to drop one of them in favor of something else.
Google Cloud Build (GCB for short)
The first tool we will analyze is Google Cloud Build, formerly known as Google Cloud Container Builder, which is a CI platform provided by the Google Cloud Platform.
GCB is a platform with a lot of potential. It is similar to other Docker-based CI platforms like Travis, Circle or Drone CI, but unfortunately is lacking community support completely and even from the Google side it looks like there is not enough manpower to answer to customer requests.
GCB uses Docker images, called Cloud Builders, to provide tools and environments required for running specific actions, such as kubectl for deploying to Kubernetes, or go for building Go binaries.
GCB is bad for cache
There is currently a large amount of missing features in GCB and the worst one is that it does not allow us to configure zones and regions for the GCE instance where the Cloud Build is running: using remote cache (for example GCS) is nearly impossible when the location is randomly selected, latency will skyrocket and the benefits of using cache is nullified by the overhead of transferring the data across the globe. Another related issue is that we cannot mount Persistent Volumes and therefore make use of local cache. Platforms like Bazel are heavily affected by this.
GCB has a bad IAM permissions management
IAM permissions are a powerful tool provided by the Google Cloud Platform, unfortunately GCB does not make good use of them (yet). You can only set the IAM permissions per-build and not per-step, this makes it impossible to use generic service accounts and instead forces you to create a single, large service account that needs to be activated before launching the build. There is no granularity and no reuse of the same permissions. If different projects need different level of access you will end up creating dozens similar service accounts.