SciJava CI has migrated from Travis CI to Github Actions. Go to the Github Actions page for configuration instructions. Repositories configured to use Travis CI are easily migrated by following the instructions on the Github Actions page. The github-actionify.sh script performs the migration automatically.
SciJava projects use Travis in a variety of ways:
- Perform builds of SciJava projects. Travis deploys
SNAPSHOTbuilds to the SciJava Maven repository in response to pushes to each code repository’s
masterbranch. So any downstream projects depending on a version of
LATESTfor a given component will match the last successful Travis build—i.e., the latest code on
- 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
- Host your open-source project on GitHub.
- Log in to Travis CI with your corresponding GitHub account and enable your repository.
- 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.
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
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.