Setting up Travis CI, Coveralls, Codacy and Bintray for your SBT based Github project

You probably heard of some of these services, especially Travis is very common one used for Github projects. You will see that part of them are pretty easy to set up, while others require a little more effort. So let’s start with Travis CI.

Travis CI

Travis, which is a continuous integration service, is one of the easy ones to setup up. First thing is to register with your Github account at https://travis-ci.org/. Then you need to sync your repositories in Travis and select the projects you want to enable (It’s pretty self explanatory in the web ui).

The last thing to enable Travis for the project is to create a .travis.yml in the root of your project. For, pretty much the simplest version, of the file you need to specify Scala as the language and the Scala version.

language: scala 
scala: 
    - 2.11.7

And that should be it to get Travis to run the build on each git push / pull request. You can also specify a script section if you need to customize the commands that Travis executes.

language: scala 
scala: 
    - 2.11.7 
script: 
    - sbt clean test

Coveralls

Coveralls is a service to visualize code coverage reports. Setting it up is a little bit more tricky than Travis CI. First thing we, again, need to create an account using our Github account at https://coveralls.io. Then we need to sync the repositories and select the ones to enable for Coveralls (Pretty much the same as we did for Travis). Next we need include two SBT plugins in our project. One is SCoverage, the tool to actually run the coverage analysis in the projct, and sbt-coveralls, which is used to send the report data to Coveralls.

addSbtPlugin(org.scoverage % sbt-scoverage % 1.3.5) addSbtPlugin(org.scoverage % sbt-coveralls % 1.0.3)

Note: the version might not be the most recent anymore

The last step is to change the .travis.yml to execute the coverage analysis and then report it to Coveralls.

language: scala 
scala: 
    - 2.11.7 
script: 
    - sbt clean coverage test 
after_success: 
    - sbt coveralls

If you have a multi-module project you additionally need to aggregate the generated reports.

language: scala 
scala: 
    - 2.11.7 
script: 
    - sbt clean coverage test 
      sbt coverageReport 
      sbt coverageAggregate 
after_success: 
    - sbt coveralls

Codacy

Codacy is a service to analyze your code quality. For Scala based projects it is using Scalacheck to do that. The setup is the easiest one from all of the services that I am showing here. All we need to do is, again, create an account via Github. Here’s the link btw: https://codacy.com/. Then we need to sync our projects as usual and select the ones we want. That’s it! Codacy will clone the project, detect the language, run the analysis and then present the code quality report.

Bintray

Bintray is a service to publish and manage packages. The nice thing is that it seamlessly works with JCenter, a maven repository that is widely used by now. In order to use it, first, as you probably already guessed, we need to create an account preferably with Github. After registration there are already some repositories set up for you. One of them is a Maven repository, which we are going to use. After browsing to the repository you should find an option to import projects from Github and that’s the next thing we need to do. After that we can link this imported project to JCenter. You should see the option when in the project view. After this has been done we need to setup up our SBT project to be able to publish the build artifacts to Bintray and respectively to JCenter. To help us with that we are going to use another plugin:

addSbtPlugin(me.lessis % bintray-sbt % 0.3.0)

Note: the version might not be the most recent anymore

Now we need to add some mandatory settings in the project. One thing that needs to be done is to set up the name, organization and version of the project, since this information is later on used to reference your project. We will also need to set a license for the project:

licenses += (Apache-2.0, url(https://www.apache.org/licenses/LICENSE-2.0.html))

Note: the available licenses can be found here: https://bintray.com/docs/api/#_footnote_1

Next we need to set up some publish settings:

publishMavenStyle := true, 
publishArtifact := true, 
publishArtifact in Test := false

So, this defines that we want to publish the artifacts in maven style, which seems to be needed such that Bintray can work with it. Furthermore, we are defining to publish all artifacts, except for the test ones.

Lastly there are some specific Bintray settings:

bintrayReleaseOnPublish := false, 
bintrayPackage := name.value, 
bintrayOrganization in bintray := None

The sbt-bintray plugin changes the sbt publish to package the project, send the artifacts to Bintray and then release them there. By setting ‘bintrayReleaseOnPublish’ to false we don’t do the publishing right away, but in a separate step. It’s not a mandatory thing, though. By setting ‘bintrayPackage’ we can pass a specific name to the package, which can be useful for multi-module projects. Lastly we set the ‘bintrayOrganization’ to None, since this is only needed when we actually set up organizations in Bintray.

Lastly we need to specify the Bintray credentials by running sbt bintrayChangeCredentials. This command will ask for the Bintray API key, which you can find when you go to the edit profile page in Bintray. Then for this changes to take effect run sbt publishTo.
Now you should be able publish to Bintray by running sbt publish and then depending on your setting sbt bintrayRelease.

So that should be all and don’t forget to add the badges to your Github project 😉

Originally published at rwlive.wordpress.com on February 21, 2016.