Recommended way for running CI / CD for Golang projects


I was wondering if there is a recommended way on how to build a go app in a CI/CD system like Jenkins or GoCD or whatever it is really?

Currently, I find myself doing something along the lines of

  • set GOPATH var to whatever JOBDIR is
  • git checkout my app into $GOPATH/src/{user}/{app}

    is this even necessary? i’m doing it because I think otherwise go get ./... will try get my own app (again) and that’d be unnecessary as it’s already checked out.

  • cd to src/{user}/{app}/ and run go get ./...
  • run dep status and dep ensure

    vendor/ is checked into git, but I think it’s worth checking that there were no local changes inside the vendor’d code and I’d expect dep ensure to then “fix” the changed code to what it actually should be - is my assumption correct?

  • run go test -cover -v ./...
  • finally run go build -o $GOPATH/../build/{appname}

Is this roughly what people generally do? Is there something that I’m potentially missing? I know about go vet but I expect that to have been run before the checkin, most editor’s golang plugin do that when saving the file.

Thanks all!

Use docker… Keeps dependencies on the build host small.

Thanks, but I’m much less about what’s on the build host or whether jobs are being run in a container, and more about good practices of how to build go apps in a CI/CD system; tasks that should be run as part of a build, how other people / companies do this and what is good / not so good about it.

Use Jenkins pipelines, but this is not specific to Go. Few related articles:


I typically use vendored dependencies, so no go get step. Instead, something like doing a normal build (to fail early if the project doesn’t even build), followed by go test with verbose and race, followed by multiple package builds. The package builds are of course scripted, but boil down to setting GOOS and GOARCH, running go build with lots of parameters for ldflags etc, and creating suitable tar / zip / deb archives.

In some cases, the resulting binary also gets deployed and restarted automatically.

I usually script things by having a build.go at the top level of the repo. It could have been a Makefile or shell script, but we already know there is a Go compiler available and not necessarily make on Windows, etc.


+1 for Jenkins. I use it all the time to execute and build Go code. It’s wonderful.

I am curious what these are and what you’re using them for :slight_smile: ? Still kind of a rookie at this Golang stuff and compiled languages in general, but if I had to guess, it’s some optimisation for ... ?


In the example I was thinking of, it’s just -w -X main.Version=... -X main.BuildStamp=... -X main.BuildUser=... -X main.BuildHost=..., so removing some extra debug info to redice the binary size a little, and setting a bunch of variable so the binary knows where it came from.

1 Like

Ah cool, I was going to look into how I can supply Version info at some point :slight_smile: … thanks Jakob!

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.