89213f9214
Update the version of protoc-gen-go-grpc that we use to generate Go gRPC code from our proto files, and update the versions of other gRPC tools and libraries that we use to match. Turn on the new `use_generic_streams` code generation flag to change how protoc-gen-go-grpc generates implementations of our streaming methods, from creating a wholly independent implementation for every stream to using shared generic implementations. Take advantage of this code-sharing to remove our SA "wrapper" methods, now that they have truly the same signature as the SARO methods which they wrap. Also remove all references to the old-style stream names (e.g. foopb.FooService_BarMethodClient) and replace them with the new underlying generic names, for the sake of consistency. Finally, also remove a few custom stream test mocks, replacing them with the generic mocks.ServerStreamClient. Note that this PR does not change the names in //mocks/sa.go, to avoid conflicts with work happening in the pursuit of https://github.com/letsencrypt/boulder/issues/7476. Note also that this PR updates the version of protoc-gen-go-grpc that we use to a specific commit. This is because, although a new release of grpc-go itself has been cut, the codegen binary is a separate Go module with its own releases, and it hasn't had a new release cut yet. Tracking for that is in https://github.com/grpc/grpc-go/issues/7030. |
||
|---|---|---|
| .. | ||
| Dockerfile | ||
| README.md | ||
| boulder.rsyslog.conf | ||
| build-rust-deps.sh | ||
| build.sh | ||
| requirements.txt | ||
| tag_and_upload.sh | ||
README.md
Boulder-Tools Docker Image Utilities
In CI and our development environment we do not rely on the Go environment of
the host machine, and instead use Go installed in a container. To simplify
things we separate all of Boulder's build dependencies into its own
boulder-tools Docker image.
Setup
To build boulder-tools images, you'll need a Docker set up to do cross-platform builds (we build for both amd64 and arm64 so developers with Apple silicon can use boulder-tools in their dev environment).
Ubuntu steps:
sudo apt-get install qemu binfmt-support qemu-user-static
docker buildx create --use --name=cross
After setup, the output of docker buildx ls should contain an entry like:
cross0 unix:///var/run/docker.sock running linux/amd64, linux/386, linux/arm64, linux/riscv64, linux/ppc64le, linux/s390x, linux/mips64le, linux/mips64, linux/arm/v7, linux/arm/v6
If you see an entry like:
cross0 unix:///var/run/docker.sock stopped
That's probably fine; the instance will be started when you run
tag_and_upload.sh (which runs docker buildx build).
macOS steps:
Developers running macOS 12 and later with Docker Desktop 4 and later should be able to use boulder-tools without any pre-setup.
Go Versions
Rather than install multiple versions of Go within the same boulder-tools
container we maintain separate images for each Go version we support.
When a new Go version is available we perform several steps to integrate it to our workflow:
- We add it to the
GO_VERSIONSarray intag_and_upload.sh. - We run the
tag_and_upload.shscript to build, tag, and upload aboulder-toolsimage for each of theGO_VERSIONS. - We update
.github/workflows/boulder-ci.ymlto add the new image tag(s). - We update the remaining
.github/workflows/yaml files that use aGO_VERSIONmatrix with the new version of Go. - We update
docker-compose.ymlto update the default image tag (optional).
After some time when we have spot checked the new Go release and coordinated
a staging/prod environment upgrade with the operations team we can remove the
old GO_VERSIONS entries, delete their respective build matrix items, and update
docker-compose.yml.