Publishing to Github releases from Travis CI

If you’re developing a node.js package, you can publish it to npmjs. If you’re developing a .NET package, you can publish it to nuget. But what if you’re developing a standalone executable, where do you publish it?

I was faced with this dilemma when I wrote ruready. Even though ruready is written in go, it gets compiled into an executable and I want the users to have a way of getting it in that form. Of course, you can always get the source code and compile it yourself but ruready is designed to be standalone and to be deployed on a machine that doesn’t have go installed (such as the Alpine Linux docker image).

Github introduced recently the releases feature. It allows repositories to publish files, up to 2 GB in size (at the time of writing), as part of a versioned release. If your build produces binaries, you can store them for free, outside of the git repository, on Github. Then Github will advertise those release as part of the repository, will keep them sorted by date, and will allow your users to download the files. That’s exactly what I needed!

Travis CI allows you to build your project and then publish the build output to Github releases. When you push code to Github, Travis can pick it up, build it, and publish it.

To publish build artifacts to Github from Travis CI, do the following:

Sign up for Travis CI. It’s free for public repositories.
Authorize it to access your github account.
In your Travis account page, enable the Travis build for that repository.

In your repository’s root, create a file called .travis.yml with the following content, in addition to everything that your build needs:

 deploy2:
     provider: releases
     api_key:
         secure: <your key>
     file: 
         - file1
         - file2
         - ...
     skip_cleanup: true
     on:
         repo: <your repository path>
         tags: true

Let’s see what each property means:

deploy:provider:release: specifies that it should publish to github release (Travis supports multiple providers).
api_key: ...: this is the encrypted deployment key. The easiest way to generate it is using the travis command line tool. Simply run travis setup releases in the repository folder and follow the steps.
file: ...: this is the list of files that will be uploaded. At the time of writing, it’s doesn’t support wildcards so you have to list each file individually. The paths are relative to the travis build directory.
skip_cleanup:true: prevents Travis CI from deleting the files after they are built.
on:repo:<your repository path>: specifies that the deploy step should only run when triggered from your repository.
- second levels
on:tags:true: specifies that the deploy step should only run when triggered by a git tag. So, it doesn’t run for pushes, pull requests, merges, etc. This is needed because Github releases are created based on tags.
```
  deploy2:
      provider: releases
```

If the example above is confusing, here’s the full file: https://github.com/victorhurdugaci/ruready/blob/master/.travis.yml. On every build with a tag, it uploads ruready (the executable) and a text file ruready.sha1 (the checksum for that release):

In addition to the two files, github also creates two archives with the source code.