Continuous Integration with TravisCI and GitHub

A few lessons learnt from setting up integration of Github and Travis CI. I’ll walkthrough the process of triggering travis CI for build and publish release back to GitHub.

A. Prerequisites:

To get started with Travis CI using GitHub #

1. Go to Travis-ci.com and Sign up with GitHub.

Enable Service Integration to Github Repo

Login to travis-ci.org. Under profiles photos (top right) > settings, enable the Github repository that you wish to select for TravisCI integration. For example:

Sample Git Repository displayed in TravisCI Settings

B. Steps to setup Integration:

Step 1: Create .travis.yml in repository root folder. I’ve a simple file structure setup as below

.
├── .travis.yml
├── README.md
├── _bin
│ ├── testfile.txt
│ └── testfile2.txt
├── sqrt.go
└── sqrt_test.go

Step 2: Execute travis setup releases

note: On Mac, run ‘brew install travis’ if you don’t already have travis CLI installed.

Instead of setting it up manually, it is highly recommended to use travis setup releases, which automatically creates and encrypts a GitHub oauth token with the correct scopes. You will get a deploy section automatically generated that looks like this.

This is an important step. If the api key is incorrectly setup, you could spends hours on debugging and fixing permission issue on release deployment.

Step 3: Fill other configs as required for .travis.yml. Sample .travis.yml

Step 4: Check Github Release

Step 4a: TravisCI Job Log

You could check the status of CI build from Travis CI Dashboard. Go to Dashboard > Branches. Click on the build link (e.g. # 23 passed) for build log.

For a successful release to Github, you will see similar output to below:

If there is a permission issue with release, you will get an warning msg as below:

Step 4b: Artifacts in Github Release

C. GitHub Releases Uploading Options

Deploying only on tagged builds

With on.tags: true, your Releases deployment will trigger if and only if the build is a tagged build.

Regular releases #

When the draft option is not set to true (more on this below), a regular release is created. Regular releases require tags. If you set on.tags: true (as the initial example in this document), this requirement is met.

Draft releases with draft: true #

With

deploy:
  provider: releases
  api_key: "GITHUB OAUTH TOKEN"
  file: "FILE TO UPLOAD"
  skip_cleanup: true
  draft: true

YAML

the resultant deployment is a draft Release that only repository collaborators can see. This gives you an opportunity to examine and edit the draft release.