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/github.com/{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/github.com/{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, 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.
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.
I am curious what these are and what you’re using them for ? 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.
? 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 
… thanks Jakob!