Using Cirrus CLI instead of Makefiles for gRPC code generation
Cirrus CLI is a tool for running containerized tasks reproducibly in any environment. Most commonly, Cirrus tasks are used as part of continuous integration workflows but Cirrus tasks can also be used as part of the local development process as a hermetic replacement of helper scripts/Makefiles that don’t rely on locally installed packages. In this post we’ll see how the boilerplate of generating gRPC definitions for Go can benefit from using Cirrus CLI.
First, let’s start with taking a closer look at the recommended way of generating gRPC definitions from the official documentation. It seems like a lot of boilerplate.
There is a need to preinstall protobuf compiler and two Go packages. Note that in the documentation versions of the protobuf compiler and Go packages are not pinned! As a result on your local workstation will always get the latest versions at the time of the first installation which most likely will be completely different from the versions of your colleague that did the setup a few months earlier.
With Cirrus CLI one can use a Docker container with a pinned version of protobuf compiler and Go packages. You can either create such a Docker image yourself or use some existing one, for example,
namely/protoc . Let’s see how
.cirrus.yml configuration file with a generation task will look like:
# To not run in Cirrus CI cloud.
only_if: $CIRRUS_ENVIRONMENT == "CLI"
# namely/protoc image tagged with a desired gRPC version.
# The image will also contain the latest protoc
# at the time of image creation.
image: namely/protoc:1.15_0 generate_script:
- cd examples/helloworld/helloworld
- entrypoint.sh -d . -o . -l go --go-source-relative
Simple as that! Now you have reproducible generation of gRPC definition regardless of what version of protobuf compile, Go and gRPC plugins you have locally installed.
To run Generate task simply type
cirrus run generate --dirty in your terminal.
By default, Cirrus CLI runs every task on a copy of your project files. The
--dirty flag forces👌 the CLI just to mount your project directory in order to persist any changes made by the task run.