a little madness

Since version 2.0, Pulse has supported plugins to extend integration with external tools. Whenever customers have asked for help with plugin implementation, we’ve always provided samples as the easiest starting point. Seeing a complete plugin project, with build and packaging support, is the easiest way to get a new plugin up and running.

Based on this we’ve decided to start maintaining a repository of open source Pulse plugins. These will act both as samples and in some cases as early versions of plugins that may migrate into the core Pulse distribution. The sample plugins are hosted in a Mercurial repository which has an hgweb interface:

http://hg.zutubi.com/

So far we have provided a sample JUnit test post-processor (simplified from the version shipped with Pulse), and the beginnings of a Subversion SCM plugin (wrapping the svn command line). Provided you have Mercurial installed, you can easily clone the samples over HTTP, e.g.:

$ hg clone http://hg.zutubi.com/com.zutubi.pulse.core.postprocessors.junits

The samples have README files to get you started.

You may notice there is a third sample: a plugin that provides basic SCM integration with Bazaar by wrapping the bzr command-line. I’m happy to report that this sample was generously donated by a member of the community, Michiel van Slobbe. Michiel is the first to try to get Pulse and Bazaar working together and we appreciate the effort! Hopefully it will provide inspiration for other community members.

Although we are happy to provide hosting for such community plugins, you may also choose your own path. Another member of the community, Orvid, is using Pulse for C#/Mono projects. Orvid has taken the initiative of writing a command plugin to integrate XBuild, the Mono equivalent of Microsoft’s MSBuild, with Pulse. You can find the XBuild plugin on GitHub:

https://github.com/Orvid/XBuildIntegration

You might also notice that Orvid has been working on a .Net wrapper for the Pulse remote API:

https://github.com/Orvid/Zutubi.Pulse.Api

These efforts are a great contribution that we are most thankful for!

Happy days: we’ve now released Pulse 2.4! Thanks to all those that provided feedback during the Pulse 2.4 beta period. Here’s a recap of the major updates in this release:

• Mercurial support: in the form of a new plugin.
• Maven 3 support: including a command, post-processor and resource discovery.
• Agents page updates: with graphical status and more convenient navigation.
• Reworked agent status tab: with more build links and efficient live updates.
• New agent history tab: quickly browse all builds that involved an agent.
• Reworked server activity tab: showing build stages nested under active builds.
• Pause server: admins can pause the build queue, so all triggers are ignored.
• New server history tab: showing build history across all projects.
• Restyled info and messages tabs: for both the agents and server sections.
• Improved process termination: to make terminating builds more reliable.
• Kill build action: for quicker build termination forgoing full clean up.
• Improved changelist views: these views have been reworked in the new style.
• Pinned builds: mark builds that should never be deleted or cleaned.
• Templated field actions: easily find or revert to an inherited value.
• Introduce parent refactoring: adjust your template hierarchy over time.
• Pluggable resource discovery: automatically locate build tools and libraries.
• Subversion changelist support: easily submit a changelist as a personal build.
• … and more: extra UI touches, improved performance, more plugin support implementations and more.

The new in 2.4 page on our website has more details and a few screenshots. Or you can simply download and try Pulse 2.4 for free.

After a few iterations of Pulse 2.4 beta builds, we’ve finally reached a stable enough state to declare our first release candidate. Since the original 2.4 beta post, we haven’t just been squishing bugs, but have come up with several more improvements:

• New agent history tab: quickly browse all builds that involved an agent.
• Pause server: admins can pause the build queue, so all triggers are ignored.
• Improved changelist views: these views have been reworked in the new style.
• Pinned builds: mark builds that should never be deleted or cleaned.
• Subversion changelist support: easily submit a changelist as a personal build.
• Faster browse view: most of these optimisations also appear in Pulse 2.3.
• Improved process termination: to make terminating builds more reliable.

We know from feedback that these changes will be popular! Check them out yourself: release candidate builds are available from the Beta Program page.

Another lull in the blog post frequency should have been a clue: we were hard at work on the next major Pulse release. So it is with great pleasure that I announce the first Pulse 2.4 beta build! This version brings further usability improvements throughout both the reporting and administration interfaces, along with built in support for new tools. Key updates include:

• Mercurial support: in the form of a new plugin.
• Maven 3 support: including a command, post-processor and resource discovery.
• Agents page updates: with graphical agent status and more convenient navigation.
• Reworked agent status tab: with more build links and efficient live updates.
• New server history tab: showing build history across all projects.
• Reworked server activity tab: showing build stages nested under active builds.
• Restyled info and messages tabs: for both the agents and server sections.
• Kill build action: for quicker build termination forgoing full clean up.
• Templated field actions: easily find or revert to an inherited value.
• Introduce parent refactoring: adjust your template hierarchy over time.
• Pluggable resource discovery: automatically locate build tools and libraries.
• … and more: extra UI touches, more plugin support implementations and more.

See the Beta Program page to download and try Pulse 2.4, and for full details.

Exciting news: we’ve made our first stable release of Pulse 2.3! This new release includes a host of new features, with an emphasis on usability and saving time. New features include:

• Concurrent project builds: increased throughput for rapidly-changing projects.
• Project and stage priorities: allow important builds to jump the queue.
• An all-new project home tab: with clearer project status.
• An all-new project history tab: with easily customised columns.
• An improved build status tab: the build status is obvious at a glance.
• A restyled my builds tab: also easier to customise.
• Plugin synchronisation from master to agents: to save on admin time.
• Improved UI performance: via more efficient live updates.
• Google Test support: integrate C++ test results.
• Terminated build status: clearly identify explicitly-killed builds.
• …much more: dozens more improvements and fixes.

Pulse is free for open source, small teams and evaluation. Why not download Pulse today and try it for yourself! Setup takes only a matter of minutes, as shown in our demo videos.

Thanks to all users that gave help and feedback over the 2.3 development cycle! We hope you enjoy using Pulse as much as we enjoy making it.

Due to popular demand, I’ve added support for multiple output files (one per test suite) to android-junit-report.

For simplicity and efficiency, android-junit-report does not produce files in the exact format used by the Ant JUnit task. In the 1.1 release there are two main differences:

1. A single report file is produced containing all test suites.
2. Redundant information, such as the number of cases, failures etc is not added using attributes on the testsuite tag.

It turns out the first of these restrictions caused multiple users issues with tools accustomed to handling a single report file per suite. So in the latest 1.2 release I have added a new multiFile option. When this option is enabled, android-junit-report produces a separate output file for each test suite. This does mean that to retrieve the results from the device you will need to pull a whole directory.

To enable this option from an Ant build, you can override the default run-tests target as follows:

You can learn more about android-junit-report and/or download the new release using the links below:

• Original blog post
• Pre-built jar downloads
• Project home and documentation
• Build Server

The Android SDK documentation offers a guide for Versioning Your Applications. In short, applications have two version fields:

1. versionCode: a simple integer that you should increase with each new release. Being an integer, the code can be processed in software (e.g. other applications) if required.
2. versionName: a free-form string you can use as the customer-facing version for your application. A typical format would be dotted-decimal (e.g. 1.2.0), although any form is allowed.

This version scheme is simple and allows you the flexibility to choose your own naming scheme. One annoyance, however, is that the version is specified in the AndroidManifest.xml file:

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
        package="com.zutubi.android.example"
        android:versionCode="1"
        android:versionName="1.0">
    <application android:name=".ExampleApplication">
        ...
    </application>
</manifest>

The problem here is that the manifest is a version controlled file that also contains other vital information about the application. This makes it inconvenient to automate stamping your application with a new version for each release.

This motivated me to create a couple of Ant tasks which make it easy to set the version of your Android applications from your Ant build. I’ve released them as part of an initial version of the zutubi-android-ant project. So far there are two tasks: setversion and bumpversion.

setversion

This task allows you to explicitly set the version code and/or name for your application to specified values. Typically these values would be specified indirectly via Ant properties. The properties would be set by some other process (e.g. automatic generation based on the date, an input prompt, a property from your build server, or an read from an unversioned properties file).

For example, to set the versions based on Ant properties, prompting if those properties are not yet defined:

<target name="set-version">
    <input addproperty="version.code" message="Version Code:"/>
    <input addproperty="version.name" message="Version Name:"/>
    <zaa:setversion code="${version.code}" name="${version.name}"/>
</target>

bumpversion

Perhaps you simply want to increment the version code and point number for your application each time you make a build. (You may also change the major.minor version at times, but that is a manual choice.) You can do this simply with the bumpversion task. By default, this task will just increment the existing version code. If you set the optional attribute bumpname to true, the last element of the version name will also be incremented. For example:

<target name="bump-version">
    <zaa:bumpversion bumpname="true"/>
</target>

If your existing manifest has a version code of 3 and a version name of 1.0.3, then after bumping you will have a code of 4 and a name of 1.0.4. Simple!

Try It Out

The zutubi-android-ant GitHub page has a full README and simple examples showing in more detail how you can use these tasks. Happy versioning!

I’ve been planning to add test case durations to the XML reports generated by android-junit-report for some time. This morning, however, the magic of open source caught up with me. I received a pull request from another GitHub user who had implemented durations already!

So, with thanks to Tim from todoroo, there is a new release of android-junit-report which outputs the duration (in seconds) for each test case. This matches the output produced by the regular Ant JUnit report task, and thus should be compatible with all tools that read the format. Durations are not added to test suites, for the same reason the test case counts are not: it would require buffering. For my own use this is no big deal, because Pulse will sum the times of all cases to give an idea of the total suite time when it is not provided directly.

You can grab this new version of (1.1, build 4) from the GitHub downloads page. Or, as always, you can access the latest release build directly from the build server (click on “jar” in the “featured artifacts” table on the right of the page).

Big news today: Pulse 2.2 has graduated to stable! This release includes a stack of new features and improvements, including:

• Build UI overhaul: all tabs improved and restyled.
• New logs tab: making it easier to access stage logs.
• Featured artifacts: choose which artifacts should appear prominently.
• Build navigator: easily move forward and backward through history.
• Working copy browser: view working copies for in progress builds.
• Move refactoring: move projects and agents in the template hierarchy.
• Template navigation: navigate directly up and down a hierarchy.
• Subscription by label: subscribe to notifications by project groups.
• Agent executing stages: see what all agents are building at a glance.
• Subversion exports: for faster and smaller builds.
• Performance improvements: key for larger installations.

See the new in 2.2 page for full details.

In conjunction with this release, we’ve also given our website a complete overhaul. The new site has a fresher look, and communicates the key features of Pulse more directly. The updates also include some new features:

• RSS feeds for news items.
• Links to our latest blog posts on the front page.
• An improved buying process, allowing multiple licenses to be purchased in one transaction.
• Self-service renewal payments – just enter your current license key and go!
• A more user-friendly downloads page.

We hope you enjoy the new release, and the new site. And please, let us know what you think!

Introduction

Ant may be unfashionable these days, but it still has its advantages. Key among these are familiarity and simplicity: most Java developers have worked with Ant, and with an Ant build what you get is what you see. A major disadvantage, though, is that Ant provides very little out-of-the-box. When you start a new project, you’ve got a lot of grunt work to endure just to get your code compiled, packaged, and tested. An all-too-common solution, in the grand tradition of make, is to copy a build file from an existing project as an easy starting point.

Over the years, though, Ant has gradually expanded support for creating reusable build file snippets. On top of this a few projects have emerged which aim to simplify and standardise your Ant builds, including:

• EasyAnt
• Ant Master Build Scripts
• Ant Script Library

Today I’ve taken my first proper look at the latter, and so far I like what I see.

The Ant Script Library

In the author Joe Schmetzer’s own words:

The Ant Script Library (ASL) is a collection of re-usable Ant scripts that can be imported into your own projects. The ASL provides a number of pre-defined targets that simplify setting up build scripts for a new project, bringing re-use and consistency to your own Ant scripts.

ASL consists of several Ant XML files, each of which provides a group of related functionality via predefined targets. For example, the asl-java-build.xml file defines targets for compiling and packaging Java code. The asl-java-test.xml file extends this with the ability to run JUnit tests, and so on. Essentially, ASL packages up all the grunt work, allowing you to concentrate on the small tweaks and extra targets unique to your project. The modular structure of ASL, combined with the fact that it is just Ant properties and targets, makes it easy to take what you like and leave the rest.

An Example

Allow me to illustrate with a simple project I have been playing with. This project has a straightforward directory structure:

• <project root>
  • asl/ – the Ant Script Library
  • build.xml – Ant build file
  • lib/ – Jar file depedencies
  • src/ – Java source files
  • test/ – JUnit-based test source files

To add ASL to my project, I simply downloaded it from the project download page and unpacked it in the asl/ subdirectory of my project¹. Then I can start with a very simple build file that supports building my code and running the tests:

<?xml version="1.0" encoding="utf-8"?>
<project name="zutubi-android-ant" default="dist">
    <property name="java-build.src-dir" location="src"/>
    <property name="java-test.src-dir" location="test"/>
    <property name="java-build.lib-dir" location="libs"/>

    <property name="asl.dir" value="asl"/>

    <import file="${asl.dir}/asl-java-build.xml"/>
    <import file="${asl.dir}/asl-java-test.xml"/>
</project>

Notice that I am using non-standard source locations, but that is easily tweaked using properties which are fully documented. With this tiny build file, let’s see what targets ASL provides for me:

$ ant -p
Buildfile: build.xml

Main targets:

 clean                 Deletes files generated by the build
 compile               Compiles the java source
 copy-resources        Copies resources in preparation to be packaged in jar
 dist                  Create a distributable for this java project
 generate              Generates source code
 jar                   Create a jar for this java project
 test-all              Runs all tests
 test-integration      Runs integration tests
 test-run-integration  Runs the integration tests
 test-run-unit         Runs the unit tests
 test-unit             Runs unit tests
Default target: dist

It’s delightfully simple!

Adding Reports

It gets better: ASL also provides reporting with tools like Cobertura for coverage, FindBugs for static analysis and so on via its asl-java-report.xml module. The full range of supported reports can be seen in the report-all target:

<target name="report-all"
        depends="report-javadoc, report-tests, report-cobertura, report-jdepend, report-pmd, report-cpd, report-checkstyle, report-findbugs"
        description="Runs all reports"/>

Having support for several tools out-of-the-box is great. For my project, however, I’d like to keep my dependencies down and I don’t feel that I need all of the reporting. Although the choice of reports is not something that is parameterised by a property, it is still trivial to override by providing your own report-all target. This shows the advantage of everything being plain Ant targets:

<?xml version="1.0" encoding="utf-8"?>
<project name="zutubi-android-ant" default="dist">
    <property name="java-build.src-dir" location="src"/>
    <property name="java-test.src-dir" location="test"/>
    <property name="java-build.lib-dir" location="libs"/>

    <property name="asl.dir" value="asl"/>

    <import file="${asl.dir}/asl-java-build.xml"/>
    <import file="${asl.dir}/asl-java-test.xml"/>
    <import file="${asl.dir}/asl-java-report.xml"/>

    <target name="report-all"
            depends="report-javadoc, report-tests, report-cobertura, report-pmd, report-checkstyle"
            description="Runs all reports"/>
</project>

Here I’ve included the java-report module, but defined my own report-all target that depends on just the reports I want. This keeps things simple, and allows me to trim out a bunch of ASL dependencies I don’t need.

Conclusion

I’ve known of ASL and such projects for a while, but this is the first time I’ve actually given one a go. Getting started was pleasantly simple, as was applying the small tweaks I needed. So next time you’re tempted to copy an Ant build file, give ASL a shot: you won’t regret it!

–
¹ In this case I downloaded the full tarball including dependencies, which seemed on the large side (21MB!) but in fact can be easily trimmed by removing the pieces you don’t need. Alternatively, you can start with the basic ASL install (sans dependencies) and it can pull down libraries for you. Sweet .