Using for testing RingoJS or other JVM-based applications

Continuous Integration and Continuous Deployment is a hosted Continuous Integration and Continuous Deployment platform. It runs your software tests in a VM and reports the result via a Web service. Since it’s not restricted to a special environment and supports JVM-based languages, it’s also an option for RingoJS developers. This short tutorial shows you how the setup looks like and what typical pitfalls are.

If you have quick iterations, a various number of feature branches and a lot of code merges per day, Continuous Integration is the way to go. But also small projects can profit from it if the effort to setup a CI workflow is low. That’s why I’m using for some of my RingoJS-based projects. The setup takes only minutes and you get a nice and straightforward workflow. In my case every push to the repository on Github triggers a build on Codeship and runs the tests. For my personal cloud-based projects I use the App Engine integration to deploy the application if everything is fine. All projects I test via Codeship are fully open source, so my security concerns are low. If you want to use their service for more critical applications, they provide an overview over their security strategy.

Codeship running and deploying a Google App Engine application.ORF.atOverview over all builds, including one failed one.

Setup Commands

The first step is to configure the “Setup Commands”, which will be executed before every test run. Here you can download Apache Ivy, which is required to update Ringo’s dependencies, and the current master of Ringo. After unzipping both ant will build a fresh Ringo installation which includes the JavaScript runtime environment and all built-in modules. In the restricted VM you cannot start Ringo with the normal shell script and have to use the java command provided by the VM’s JDK.

Test Commands

After the setup commands you can execute your Ringo tests by invoking Ringo via the run.jar, which contains the previously built runtime. If your tests fail, Codeship will send you notifications and you can see the stack trace in the build’s output.

How a build looks like

All steps are listed in the details of a build. If a step fails, you can click on it and see the output on the console. Codeship shows you the author, the branch and SHA hash of the commit and how long each step took.

Codship building a new version of the

For me Codeship is a convenient addition to my workflow. In my opinion the biggest advantage is that you can always test your Ringo packages against the latest master from Github and don’t have to update your local clone / fork. I configure the build and define the test commands and every push to the repository will be tested without any exceptions. Just yesterday, you see this failed build in the first screenshot, I forgot to update my Datastore index definitions for a RingoJS-based Google App Engine application and Codeship immediately sent me an e-mail with an error report, which reduced the downtime to a minimum. On the other side you externalize your build workflow and this might not be a solution for everyone. You have to consider carefully whether an external CI-service will improve your workflow or if you keep relying on your local set of tools.

Philipp Naderer-Puiu,