letsencrypt
/
boulder
mirror of https://github.com/letsencrypt/boulder.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
boulder/test/boulder-tools
History
Andrew Gabbitas 3bb3421631
Remove go 1.17.5 from test matrix (#5940) 		2022-02-12 12:03:23 -07:00
..
Dockerfile test: Install arm64 protobuf for arm64 docker images (#5880) 2022-01-13 13:45:38 -08:00
README.md Remove Travis-CI (#5356) 2021-03-19 17:49:05 -07:00
boulder.rsyslog.conf Add log validator to integration tests (#4782) 2020-04-20 13:33:42 -07:00
build.sh test: Install arm64 protobuf for arm64 docker images (#5880) 2022-01-13 13:45:38 -08:00
requirements.txt Make boulder-tools image smaller. (#4732) 2020-04-06 16:53:42 -07:00
tag_and_upload.sh Remove go 1.17.5 from test matrix (#5940) 2022-02-12 12:03:23 -07:00
upgrade_publicsuffix_go.sh Add script to perform weppos/publicsuffix-go upgrades (#5661) 2021-10-13 18:45:08 -07:00

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.

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:

  1. We add it to the GO_VERSIONS array in tag_and_upload.sh.
  2. We run the tag_and_upload.sh script to build, tag, and upload a boulder-tools image for each of the GO_VERSIONS
  3. We update .github/workflows/boulder-ci.yml, adding the new docker image tag(s) to the BOULDER_TOOLS_TAG section.

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.