This post is a summary of my research on building Go projects in a Docker container on CI (Gitlab, specifically). I found solving private dependencies quite hard (coming from a Node/.NET background) so that is the main reason I wrote this up. Please feel free to reach out if there are any issues or a submit pull request on the Docker image.
### Dep
As dep is the best option for managing Go dependencies right now, the build will need to run`dep ensure`before building.
Note: I personally do not commit my`vendor/`folder into source control, if you do, I’m not sure if this step can be skipped or not.
The best way to do this with Docker builds is to use`dep ensure -vendor-only`.[See here][1].
### Docker Build Image
I first tried to use`golang:1.10`but this image doesn’t have:
* curl
* git
* make
* dep
* golint
I have created my own Docker image for builds ([github][2]/[dockerhub][3]) which I will keep up to date - but I offer no guarantees so you should probably create and manage your own.
### Internal Dependencies
We’re quite capable of building any project that has publicly accessible dependencies so far. But what about if your project depends on another private gitlab repository?
Running`dep ensure`locally should work with your git setup, but once on CI this doesn’t apply and builds will fail.
### Gitlab Permissions Model
This was[added in Gitlab 8.12][4]and the most useful feature we care about is the`CI_JOB_TOKEN`environment variable made available during builds.
This basically means we can clone[dependent repositories][5]like so
Using the`.netrc`file allows you to specify which credentials to use for which server. This method allows you to avoid entering a username and password every time you pull (or push) from Git. The password is stored in plaintext so you shouldn’t do this on your own machine. This is actually for`cURL`which Git uses behind the scenes.[Read more here][6].