Occasional Go #1 — Travis CI

8 min readFeb 12, 2018

A recipe for setting up Travis CI on your Go projects.

TL;DR — Skip to bottom for full recipe.

Whether you’re an expert or beginner, building a toy program or production app, alone or with a team; Travis CI is an invaluable resource in your development toolkit. Providing automated, immediate feedback on code correctness, quality, and other user-defined behaviors.

This is very sales-pitch’y. I’m not sure I want to keep reading.

I’m not being paid by Travis-CI, I swear! Please keep reading! 🙏

If my awesome intro didn’t quite communicate everything, Travis CI is a platform to perform user-defined actions on every commit, push, pull-request, etc. on a GitHub repository. Those actions are defined in a simple configuration file .travis.yaml. YAML is just a markup language, think JSON if that is more familiar, for writing structured information.

Since this post is just an intro to using Travis CI, I’ll assume you already have:

A repository on Github of Go code that compiles with go build
You are the owner of the repo, or have admin/owner permissions and don’t mind muck’ing around a bit

Turning on Travis CI

First things first. Before we can get to configuring Travis for our application, we need to enable it. Head on over to travis-ci.org and log in with your GitHub account. Then click on your name at the top-right:

This will take you to your profile where you can enable Travis for any of your GitHub repositories. It may look something like:

You can toggle repos on or off and click the little gear icon for more settings. These settings let you define when you’d like Travis to run. The defaults should work for our post, but I’ll let you explore those settings on your own.

For the remainder of this article, you can make your changes in a separate branch and open a pull-request on your GitHub repository. Every time you push a change to your .travis.yaml file, Travis CI will run on your code.

The Basics

In order to start writing our .travis.yaml file, we need to first write some basics in the file.

This is the bare minimum required for Travis to understand that we are building a Go project. By listing the versions we’d like to use, Travis will spin up a build for each. This is extremely useful if you are writing a library intended to be used by a wide-range of people. Or, perhaps, you’re just curious to know if your program still works on the latest Go version.

master, in this case is the latest, unreleased changes to the Go language. Because of this, we may want to know if our code works on master but not require it.

What do you mean require? Like sometimes Travis won’t run on master or something?

Oops! So I may have missed an important concept. The act of performing actions on Travis is called a “build.” The result of the build is either a pass or fail. Think of all those green, and sometimes red, badges you see on GitHub repos, those are build results. They look like this:

So, back to the question of master. All we want to tell Travis is that we want to run our commands with Go master version, but we just don’t want it to fail the build if there are problems. For this, we can add:

This should be pretty self-explanatory, except perhaps for fast_finish. This is a simple flag that means “don’t wait for the non-required build.” So when you push up your change and it builds for all your specified Go versions, it’ll only wait for the required ones to finish before telling you if the build passed or failed.

Installing Dependencies

If you’re just relying on plain ‘ole go get to manage your dependencies, then you don’t really have to do anything, luck you! Travis will automatically run

go get -t ./...

This will automatically fetch the latest versions of your dependencies required by your code (including your tests). However, if you’ve moved on to using a package manager, then you may need to add a section to run a custom command. If you are using dep, then you can add the following section:

You can fill in the install step for whatever dependency management tool you use. However, Travis doesn’t come installed with all our favorite dependency management tools. You’ll need to install them. We can do this with a pre-install step:

This is the general way to install tools on Travis before getting going with your build. If install vs before_install are confusing, just think that install is about installing your application and before_install is for installing other applications required to install and build your application. We’ll revisit this section later.

P.S — If the weird >- thing is tripping you up, it’s just a magical YAML incantation that let’s me split my super long-winded curl command into mulitple lines.

Compiling & Running Tests

This is the bare basics of what Travis should be doing for us, since it’s what we should be doing after each change, locally. 😉 By default, Travis will run

go test -v ./...

Or, if you have a Makefile it will run:

make

Since we don’t have, or want, a super complex build, simply using the .travis.yaml file will suffice. And, for the moment, the default behavior will suffice. We’ll expand on it in the next section.

Running Static Analysis Tools

Static analysis tools are programs that look through your code and tell you what to fix or improve. These tools are awesome for learning idiomatic, correct programming in Go and is valuable for programmers at all levels. There are quite a few tools available to the Go community:

go vet — Reports potential errors that otherwise compile
deadcode — Finds unused code
errcheck — Finds unchecked errors
golint — Google’s style checker (dos and don’ts of idiomatic Go code)
maligned — Finds structs that could use less memory if aligned better
gas — Scans for security problems

There are actually quite a few more, but this should give you an idea of the variety of functionality these tools offer.

This is super neat! But, which ones do I use? Should I use all of them? Wow, if we use all of them I’m going to be here forever… Don’t you think this post is long enough?

You’re right, this is a lot of tools to install/setup/use. Lucky for us there is a project, gometalinter, that allows us to install and run all of these tools at once. It even combines and prints results in a unified format. Let’s get it installed in our .travis.yaml:

Note that I’ve left out what was added earlier; they are combined all at the end of the article. The go get downloads the gometalinter project and the second line installs all of the linters that gometalinter wraps.

To run, we simply add a script block, making sure not to re-add the default behavior we are now overriding:

This will run all of the linters on our code. If we want to restrict which linters get run, then we can instead use:

Which linters you use is up to you; the full list is available on the gometalinter GitHub page.

Getting Notified of Results

You’ve got Travis CI doing all kinda of work: installing dependencies, building and testing your code, and performing various static-analysis checks. What now?

Well, now you would like to be made aware of the results. Basic information of the pass/fail sort is automatically provided by Travis on your pull request, assuming this is what triggered the build, in the form of:

But what about when this merges and possibly starts a build for your master branch? How do you get those results?

Email Notifications

This sets up who gets the email and when. change here means that notifications are only sent when the status changes to success from a previous failure. always means that notifications are always sent for failing builds, regardless of what the previous build-result was.

Or… If you think email is dead and should never be used, it can be disabled:

Why would you disable notifications? Maybe you just don’t want to get all those emails, or maybe you prefer using something like Slack. Travis supports a lot of integration options, so maybe go checkout the docs and see how to integrate your favorite platform.

The Badge of Honor (or Shame)

Congratulations! You’ve done all this awesome work and now it’s time to display your badge of honor on your GitHub page! To get the source for this badge, go your project page on Travis CI. Click the badge on your page:

Which will bring up a dialog for you to pick the branch, and format you’d like to use. If you have a readme.md file, then you’ll want something like:

Just copy-paste that into your readme.md and you’ll now have your badge of honor. Just be careful not to let it turn into a badge of shame with a failing build. 😉

Final Config

Putting all our previous snippets together, we get the final .travis.yaml:

Woot! You’ve done it! 🎉

Now go open a PR and watch all the magic happen!

Occasional Go is a semi-regular series on the Go programming language, offering short’ish guides and tutorials on narrow topics. You can keep up to date on the latest posts by following me, John Murray, on Medium and please 👏 if you enjoyed the post.