• A new warning status, making it easier to work with builds with warnings.
• The ability to reference properties in SCM configuration.
• Another new stage hook points on stage termination.
• Upstream change reporting to show how dependencies influenced a build.
• Dependency notifications to show how your changes affected downstream builds.
• Artifact archives, allowing easy delivery of directory trees between projects.
• Flexible bootstrapping allows control over how your builds are prepared.
• Subversion 1.7 working copy format support.
• Git submodule support.

Our plan now is to focus on performance and stability for the next few builds before pushing 2.5 as the stable release. In the mean time you can find out more, and even try beta builds, by visiting our beta program page. Happy building!

• Browse and dashboard view filtering (by project health).
• A new MSTest post-processor plugin.
• Increased visibility of build (and other) comments.
• Comments on agents, to communicate with other users.
• Properties on agents, for simpler parameterisation.
• The ability to configure SCMs using resources.
• A resource repository on the Pulse master.
• A new option to attach build logs to notification emails.
• Pre-stage hooks, which run just before the stage is dispatched to the agent.
• SCM inclusion filters, complementing existing exclusion filters.
• Inverse resource requirements (i.e. requiring the absence of a resource).
• Smart label renaming.
• A separate permission for the ability to clean up build directories.
• Support for Perforce streams.

There’s plenty more to come in subsequent alpha builds, too. In fact, we’ve started the groundwork for some other larger changes already in 2.5.0.

To grab yourself a fresh-from-the-oven 2.5 alpha build, or just to find out more, head over to our alpha program page.

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!

• 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.

• 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.

• 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.

• 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.

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

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!

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).