# Travis

"""Travis CI:""" Build your code in the cloud!

Travis CI is a tool for continuous integration. It has excellent integration with GitHub, and is very useful for automating builds, deployment and other tasks. <div class="toc"></div>

# Services

ImageJ and SciJava projects use Travis in a variety of ways:

• Perform builds of SciJava projects. Travis deploys SNAPSHOT builds to the SciJava Maven repository in response to pushes to each code repository’s master branch. So any downstream projects depending on a version of LATEST for a given component will match the last successful Travis build—i.e., the latest code on master.
• Run each project’s associated unit tests. Travis is instrumental in early detection of new bugs introduced to the codebase.
• Perform releases of SciJava projects. Travis deploys release builds to the appropriate Maven repository—typically either the SciJava Maven repository or OSS Sonatype.
• Keep the javadoc site updated.
• Keep other web resources updated.

# Automatic Deployment of Maven Artifacts

Deploying your library to a Maven repository makes it available for other developers. It is also a contribution requirement for the Fiji project.

## Requirements

• Host your open-source project on GitHub.
• Contact an ImageJ admin in Gitter or the Image.sc Forum and request that they file a PR which adds Travis support to your repository.

## Instructions

In order to add Travis CI support to a repository, the SciJava credentials are needed: A) for deploying to Maven repositories; and B) in the case of deploying to OSS Sonatype, for GPG signing of artifacts. If you have a copy of these credentials, and admin access to the relevant repository on GitHub, you can use the travisify.sh script to perform the needed operations. This script requires the travis command line client to be installed, and you may need to run travis login to authenticate first. If you need help, please ask on the Image.sc Forum in the Development category, or in the scijava-common channel on Gitter.

## Testing things which cannot run headless

If your tests require a display (i.e.: they do not pass when run headless), you can use Xvfb as follows:

before_script:
- "export DISPLAY=:99.0"
- "sh -e /etc/init.d/xvfb start"
- sleep 3 # give xvfb some time to start


Of course, you should do this only as a last resort, since the best unit tests should not require a display in the first place.