Automation

The other day a colleague asked if I had ever tried to set up any of my GitHub projects using one of the free CI services available. I hadn't but thought it an interesting thing to do. It proved to be a ridiculously easy task.

I could find two service providers on the market. One is BuildHive from < href="http://www.cloudbees.com/" target="_blank">CloudBees. This is the the company behind the CI server Jenkins. The other is called Travis CI and is provided by Travis. Travis id a, to me new, CI company who also seem to offer some enterprise services in the cloud.

I have used Jenkins allot in the past and it's a very good CI server. The company behind, CloudBees, also offer an enterprise service which I think is a very good fit for any company who want to get first class support with their CI and CD needs. However I choose to go with Travis since they requested less permissions to my GitHub account. I have not contacted CloudBees yet to find out why the want write access to my account setting, followers and private repositories when I just want to build public ones but I'd like to know.

There are three simple steps to go through to set up Travis CI with your GitHub projects:

  1. Log in to Travis CI using your GitHub OpenId.
  2. Enable the project you want to build in the Travis CI control panel.
  3. Add the .travis.yml build script file matching the needs of your build to your project on GitHub.

It is literary this simple. Granted, the project I selected has no special requirements. It builds nicely (well actually it doesn't since I have test failures) with just a simple mvm install command. But I think this is remarkably easy and something that everyone should try. If for no other reason so just to have the experience of how simple some things in software can be when done well.

Thanks Travis CI for such a spotless integration!

I wanted to automate start of my SLAMD server for faster development time when porting on façades to the underlying SLAMD system. SLAMD ships with a Tomcat 6 server so the obvious way to do this is to use the Cargo plugin for Maven.

Below is the configuration that automatically pushes my classes to the server and then starts the server. They are configured in a profile since I don't want this to happen on all builds.

This will first remove any classes from the SLMD web app in the Tomcat container that lives under the package com. It will then copy all built classes to the SLAMD server. It will then launch Tomcat and wait for a ctrl-c to break execution. This will all happen in the package build phase.

This makes it fairly quick to deploy and test changes made to extensions of the SLAMD server.

2 Comments

After having automated our android project and getting everything to work, up and running on hudson and so on, we realised that the Android manifest xml file did not get automatically updated with the correct version numbers.

My initial idea was to use normal Maven properties, we do that in other parts of the project, to populate the values. However this does not work since the versionCode attribute must have an integer value for Eclipse to work. This ment that I would need to change the actual values in the manifest.

I had read a couple of blog posts about a Maven plugin called GMaven that have intrigued me. The plugin makes it possible to embed a Groovy script into a pom file and execute it during the build. Since Groovy makes changing XML easy this was the perfect fit.

Below is a script, embedded into the pom directives needed, that will automate setting version in the AndroidManifest.xml. It is triggered using the profile manifest-version-update. When triggered it will set the versionName attribute to the maven project version. It will also increment the versionCode attribute with 1 (versionCode++). The script should be placed in the Android application pom (I.E if you use a hierarchical structure this does not go in the parent pom).

I have yet to figure out how I can automatically trigger this when running the Maven release plugins prepare step. It would be perfect if it can be triggered once for the release pom and once for the snapshot pom during the release:prepare phase so that both the release tag and the trunk of the project has the correct version numbers. But that will have to wait a while.

When creating an application that will be distributed to more then your self you want to do it the proper way. So far I have looked at how to automate the build, testing and both using Maven, as well as how to sign the apk. What is still outstanding is to run zipalign, a tool in the Android SDK to optimise the package.

To understand what the zipalign tool is you will find Androids documentation here.

It is a simple thing to add the command to the pom file. I am assuming that your project structure looks like the examples build in the previous posts.

In the pom for your application you need to add the following snippet:

This will bind execution of zipalign to the package phase, just after the apk signing, when running install with the sign profile. It will overwrite previous zip aligned file without asking.

One function that have not yet made it in to the Maven Android plugin is application signing (it is raised as an issue). It is however possible to achieve this using the maven jarsigner plugin with some simple configuration of the pom.

It is assumed that you are using the project structure presented in previous blog posts on maven android automation (1, 2, 3)

In your parent pom you add the following profile:

Replace the following values in the above snippet:

  1. keystore the path to your key store.
  2. keypass the password for the key that will be used.
  3. storepass the password for the key store.
  4. alias the alias for the key to use.

To sign the apks, including the tests, use the following command:

The configuration will bind the jarsigner plugin to the package phase of the execution when enabled with the -Psign switch in the build. Rather then storing the passwords in clear text in your pom you can pass them to maven as arguments when you execute the command. Go to the jarsigner plugins documentation page for information on how it works and how it can be configured.