Tag: jenkins

Android App With Jenkins

I just got involved with a mobile project, and let my inner devop out for a moment… So, here’s how I got Jenkins to build, sign, and deploy an Android app for testing.

Our setup:

  • Jenkins CI, installed on a virtual Ubuntu server,
  • Android SDK on the Ubuntu server,
  • Android SDK compoments (including an Android profile/ target),
  • an Android project
  • keytool on Ubuntu to create a simple keystore, for signing the app

The gist of the Jenkins job is:

  • Get updated code from Git
  • Execute shell command to create an ant build file on the fly with the Android SDK tool android:
/opt/android-sdk/tools/android create project -n [name of resulting app file] -t [Android target] -p [name of temporary directory where project is copied and ant files generated] -k [package] -a [default app class]
  • Copy resulting build.xml from the temporary directory to the project root
  • Run ant targets clean release, with the following properties:
sdk.dir=/opt/android-sdk
target=[Android target]
key.store=path-to-keystore
key.alias=[alias]
key.store.password=[pw]
key.alias.password=[pw2]
  • (Without the last four properties above the job will build an unsigned app)
  • Publish resulting .apk via FTP to a server
And on my phone:
  • Allow installing apps from unknown sources

I got useful info from an article on jenkins-ci.org:  Getting started: Building Android apps with Hudson. My needs were a bit simpler, so you’ll see a bit more details there than here.

A few problems I had:

  • The Ubuntu VM didn’t have X installed, and getting SDK components seems to require a GUI. I tried to go around this by copying tools and targets from SDK on my laptop.
  • A bit later I got stumped by an error message on aapt and “no such file or directory”. (This might have been related to what I did on the previous problem…) An answer on stackoverflow regarding ia32-libs provided the solution in my case.

This project is a side project with low activity compared to a day job, so right now this job is a one-click deploy job (one click plus downloading and installing on the phone…) However, I think we’ll set up nightly polling, so there’s an updated app available every morning for testers, and they can see by the timestamp  if there were any updates the previous day.

JavaScript Unit Testing with Hudson and JasmineBDD

Ingredients:

  • JasmineBDD, a JavaScript BDD/ TDD framework
  • The JUnitXmlReporter from Jasmine Reporters
  • Envjs (embedded with the Jasmine Reporters download)
  • Hudson Jenkins (continuous integration server) on a Linux slave

Recipe:

  • let Hudson execute a (Java) shell command
  • let Java run Envjs
  • let Envjs run a simple JavaScript which loads an HTML file (your JasmineBDD test runner)

Voila!

The Java command:
java -cp lib/envjs/js.jar:lib/envjs/jline.jar org.mozilla.javascript.tools.shell.Main -opt -1 -f lib/envjs/envjs.bootstrap.js -f test.js
(The libs and the bootstrap file came with Envjs in the Jasmine Reporters download.)

The test.js content:
window.location = 'SpecRunner.html';
(I.e., opening the JasmineBDD spec runner.)

Simple Unit Testing Only

So far, this only works for simple unit testing for me.  F.ex., it won’t play nice with prototype (which is really integration testing, but still).

It’s probably got something to do with Envjs’ limitations compared to a full web browser.

But hey, headless automatic JavaScript unit testing ain’t bad 🙂

Update:
@ingesol got Hudson to run Jasmine using JsTestDriver and Jasmine JsTestDriver Adapter.  (See guide to Hudson and JSTD.)

It’s not headless – requires running JSTD server and browsers, but it will handle prototype et al.

Update 2:
Headless testing as described above is not only for simple unit testing – jQuery works fine, too.  There’s advantages to running a JsTestDriver server, especially catching browser quirks, but for much of the BDD/ TDD effect (testable code, design, executable requirements, etc) you can run headless testing continuously in Hudson without any “external help”…