Travis: Continuous Integration for GitHub Projects
In a recent project I got the opportunity to work with Travis, a lean, hosted continuous integration service used to build GitHub projects that is free to use for public repositiories. This post gives a brief introduction on how to build projects with Travis.
Simple Setup
Setting up Travis to build your own project(s) is quick and straightforward: Once you have signed in with your GitHub account and granted Travis a set of access permissions, you can select which repositories should be built.
From there on a build is triggered whenever a commit is made. Though Travis can somehow build the code, you usually will want to add a file named .travis.yml
to the root of each of the selected repositories. This YAML format text file specifies how you want your project to be built.
A minimal .travis.yml
for a Java project can be as short as:
language: java
as long as you use a common build system such as Gradle, Maven or Ant.
A slightly longer .travis.yml
might look like this:
jdk: - openjdk6 script: mvn verify after_success: - chmod a+x deploy.sh - ./deploy.sh after_failure: - cat com.codeaffine.module-a/target/surefire-reports/*.txt - cat com.codeaffine.module-b/target/surefire-reports/*.txt
Each build runs in a separate virtual machine image that can be customized with additional packages, users, environment settings and so on. After a build is done, the virtual machine image is reset. This approach ensures that there is a clean and consistent environment for each build. However, there is another consequence to this: All build output that you want to keep for later use must be saved somewhere else.
Deployment
Since Travis is meant to build GitHub projects, it integrates well with GitHub Releases. With a few extra lines in the .travis.yml
, arbitrary files can be uploaded to GitHub Releases. But this is just one deployment option among many – see the deployment guide for a full list of out of the box supported providers. If build artifacts should be sent somewhere else, you can always hook into the after_success
event. Like shown in the example above, the deploy.sh
script could push the build artifacts to a repository, e.g. under the gh-pages
branch.
What is kept forever though is everything that is written to the console during the build. If a build fails, you may want to cat
error logs or test reports to the console to preserve them like shown in the above example. That might help you to diagnose the failure.
Pull Requests
Travis not only builds every commit that is made by repository collaborators but also takes care of Pull Requests. Every commit in the Pull Request triggers a build that – once done – leaves a comment in the Pull Request discussion.
That way you can see if a Pull Request breaks anything without any effort.
Build Status
By default, email notifications are sent if a build fails. However, the notification policy is configurable. Recipients, occasions (success or failure) and channels (email, IRC, Campfire, webhooks, etc.) can be specified in the .travis.yml
file.
To publish the build status, for example on the project’s home page, you can embed a link to an image that indicates success or failure .
Try It Yourself
If you come to the Travis homepage for the first time, you will notice the ever-changing sidebar that shows all currently building projects. This is a good opportunity to browse around and see who else is using Travis.
Now it is your turn to take Travis for a spin if you like. You’ll be up and running really fast. In case you need assistance, browse the Help menu of the main page. There you will find links to the extensive documentation, a mailing list, and an IRC channel.
Besides Travis CI for open source projects, there is also a commercial offering for private repositories and an on-site version.
- Extras for Eclipse: Neon Update - 6. July 2016
- What’s the Difference? Creating Diffs with JGit - 16. June 2016
- Terminate and Relaunch in Eclipse - 19. April 2016