Containerize Your Go Developer Environment – Part 3

In this series of blog posts, we show how to put in place an optimized containerized Go development

In this series of blog posts, we show how to put in place an optimized containerized Go development environment. In , we explained how to start a containerized development environment for local Go development, building an example CLI tool for different platforms. covered how to add Go dependencies, caching for faster builds and unit tests. This third and final part is going to show you how to add a code linter, a GitHub Action CI, and some extra build optimizations. We’d like to automate checking for good programming practices as much as possible so let’s add a linter to our setup. First step is to modify the Dockerfile:

:1.14.3-alpine base

build

unit-test

:v1.27-alpine lint-base

lint

bin-unix

We now have a lint-base stage that is an alias for the golangci-lint image which contains the linter that we would like to use. We then have a lint stage that runs the lint, mounting a cache to the correct place.

As for the unit tests, we can add a lint rule to our Makefile for linting. We can also alias the test rule to run the linter and unit tests:

all: bin/example

lint unit-test =local

bin/example

:

    

docker build . –target bin

    –output bin/

    –platform

unit-test

:

    

docker build . –target unit-test

lint

:

    

docker build . –target lint

Now that we’ve containerized our development platform, it’s really easy to add CI for our project. We only need to run our docker build or make commands from the CI script. To demonstrate this, we’ll use GitHub Actions. To set this up, we can use the following

file:

[ ] :    :     

    

    

:

       

    

:

     -

       

     -

       

     -

       

     -

       

     -

       

Notice that the commands we run on the CI are identical to those that we use locally and that we don’t need to do any toolchain configuration as everything is already defined in the Dockerfile! Performing a COPY will create an extra layer in the container image which slows things down and uses extra disk space. This can be avoided by using and bind mounting from the build context, from a stage, or an image. Adopting this pattern, the resulting Dockerfile is as follows:

:1.14.3-alpine base

bin-unix

bin-linux

bin-darwin

bin-windows

bin

The default mount type is a read only bind mount from the context that you pass with the command. This means that you can replace the with a wherever you need the files from your context to run a command but do not need them to persist in the final image. Instead of separating the Go module download, we could remove this and just use a cache mount for . This series of posts showed how to put in place an optimized containerized Go development environment and then how to use this same environment on the CI. The only dependencies for those who would like to develop on such a project are Docker and make– the latter being optionally replaced by another scripting language. You can find the source for this example on my GitHub: You can read more about the experimental Dockerfile syntax here: If you’re interested in build at Docker, take a look at the Buildx repository: