Pulse boasts all the features you expect of an fully featured continuous integration server, along with some that are rarely found in competing systems:

Details of each feature are given below.

detailed feature list

supported build tools

Pulse can build any project that can be built from a command line. Unlike other build servers, Pulse provides first class support for executing arbitrary commands. This feature is the core on which all specific tool support is built. For example, Pulse will extract error and warning messages from supported tools out-of-the-box, but you can easily add this behaviour for other tools by specifying your own regular expressions to capture the information.

Pulse ships with support for the following tools:

SCM integration

Pulse supports:

Integration with these SCM servers provides:
  • trigger on change: trigger a build when a change is submitted to the SCM server.
  • see what changed: view everything that changed between one build and the next.
  • changelist view: view details of each change (including virtual change sets for CVS).
  • tag built revisions: tag your source after a build, e.g. to maintain a moving tag that marks the latest revision that was successfully built
  • latest changes by me: view your most recent changes on your dashboard.
  • latest changes to my projects: view most recent changes to the projects you have chosen to display on your dashboard.
  • latest changes to a project: view most recent changes to a project on the project's home page.

testing tools

If you are serious about continuous integration, then test results have to be a first-class part of the result of a build. By post-processing test reports generated during the build, test results are integrated into the Pulse interface and notifications. Pulse has first-class test support that includes:

  • easy integration: simply select a post-processor to apply to your test report.
  • extensibility: plugin support for your own testing libraries.
  • viewing test summaries: as part of the build result in the web interface.
  • failed test highlighting: in build summaries and notifications include full details of any failed test cases.
  • "broken since" links: links back to the build where a test was first broken.
Pulse has built-in support for: Other tools may be integrated by either:
  1. Producing a compatible XML report (e.g. TestNG can produce JUnit-compatible reports); or
  2. Writing a post-processor plugin to read the native reports for that tool.

flexible build scheduling

Pulse supports a variety of mechanisms that can be used to trigger the automatic build of a project:

  • scm server change monitoring: triggers a build when a change is made to your project's source code.
  • cron-style schedules: allow you to specify flexible, regular schedules (e.g. build every half hour, build every second week day at noon).
  • dependency triggers: trigger a build of a project when a build of one of its dependencies completes, filtered intelligently to prevent redundant builds
  • manual triggers: schedule a build manually via the web interface.
  • event-based project triggers: trigger a build of a project when another project build completes, filtering by the build status.
  • remote triggers: use the remote API to trigger a build on any external event.

build notifications

Pulse can notify you when a build has completed via:

  • email (plain text or HTML),
  • Jabber instant messaging,
  • RSS feeds, and
  • the Windows system tray (using Stethoscope).
Every developer has their own notification preferences which allows them to control:
  • how they are contacted: by specifying email addresses and/or Jabber accounts.
  • what projects they are interested in: by subscribing to just those projects.
  • when they are notified: by specifying notification conditions (e.g. notify for any changed or failed build).
You can also configure post build hooks to execute on build completion, allowing arbitrary notifications to be hooked in.

Pulse notification messages are fully customisable by writing Freemarker templates. If you prefer a different layout or format, you can easily add your own template to the list of choices provided by default.

capture build artifacts

The artifacts created by your build process include binary files, libraries, reports and packages. These artifacts can be easily viewed and downloaded via the Pulse web interface. The following types of artifacts are supported:

  • files: such as binaries can be captured for viewing and downloading.
  • directories: groups of files nested under a directory can be captured and wildcard filters can be used to select just the files you need.
  • html reports: created by other tools can be captured and browsed through the web interface.
Artifacts may optionally be marked as "featured", making them appear more prominently in the UI.

incremental builds

If you manage a large project with a long build cycle but require rapid feedback on source code commits, then the Pulse incremental build feature can be used. You can set up a continuous, incremental build and do full clean rebuilds overnight when the time is available. Of course you can manually force a clean rebuild at any time.

personal builds

You can submit outstanding source code changes directly to Pulse for testing before you commit them to your SCM server. This personal build feature allows you to diagnose and fix any failures without affecting the shared code base. Changes can be provided as standard patch files (e.g. unified diffs), or Pulse can generate the patch for you from your working changes.

This feature works particularly well with distributed builds across multiple platforms. Pulse allows developers to work in their chosen environment, and then test against multiple environments before checking in. Say goodbye to broken builds!

distributed builds

Pulse has the ability to distribute builds across multiple machines ("agents"). This allows both parallel and multi-platform testing. The distributed build model in Pulse is more powerful than simple remote building. It allows you to:

  • configure builds that run across multiple agents: in parallel where possible. The build only succeeds if it passes on all agents.
  • configure external resources: for agents to test against different third-party dependencies (e.g. different JVMs).
  • dispatch builds based on agent capabilities: allowing efficient use of an agent pool.
  • nominate part time agents: through a loosely-connected model thus allowing development machines to run builds overnight!

project dependencies

Pulse has built-in support for project dependency management, allowing you to declare dependencies between your projects and deliver built artifacts between them. Smart triggering is also used to build a project when one of its dependencies has changed.

Dependency support is built on Apache Ivy, making it interoperable with projects that already use Ivy. Pulse can act as an Ivy repository both for internal projects and external ones.

changelist isolation

Who broke the build? With the changelist isolation option, you can ensure each build has at most one new source code change. If the build breaks, there will be no doubt which change it was!

resource dependencies

Resources dependencies such as compilers, libraries and runtimes required for your project can be managed via the Pulse web interface. You can:

  • version dependencies: to run against different versions of these dependencies (e.g. different JVMs) without changing your build scripts.
  • specify resources: to influence the build path, environment and pulse file properties.
  • apply machine-specific resources: for each build agent, isolating your build scripts from these details.
  • specify build agent capabilities: so that builds are dispatched to agents based upon capabilities of the agent (i.e. resources available on the agent).
Pulse will automatically discover and configure common resources for you! Discovery is even pluggable.

project priorities

Projects, or individual stages within them, may be assigned priorities to affect how they are scheduled. Projects with a higher priority jump ahead of those with lower priority in the build queue. This allows you to get important builds out quickly, without needing to manually interrupt other projects.

manual build properties

Once you have Pulse running your automated builds, a natural next step is to build full releases. Often the process of building a release requires manual input of properties such as a version number. Pulse makes this simple by allowing you to configure certain projects to prompt for property information when they are triggered.

automatic cleanup

Pulse supports configuration of cleanup rules for automatic cleaning of your build history:

  • choose your units: cleanup after a certain number of builds or a time frame.
  • configure multiple rules: choose different policies for different build sets.
  • filter by result: only clean builds in chosen states.
  • pin important builds: to exempt special builds from the cleanup process.

reporting ui

Pulse includes a full web interface for reporting on build results. The web interface is not a simple billboard for build results, it is a full-blown application with individual user logins and preferences. UI features include:

  • configurability: customise the information you see to separate signal and noise,
  • dashboard view: see the status of your projects and how your changes have affected them,
  • liveness: AJAX-powered refreshing of live build information,
  • project home pages: see the most important information for a project at a glance,
  • detailed views: drill down into the gory details of your builds.

extract information

Knowing that a build failed is not very useful unless you can find out why. Pulse allows you to extract errors, warnings and other useful information from build artifacts (including command output) via post-processing. The following post-processors are provided out-of the-box:

  • regular expressions: allow you to create your own custom post-processors, capture context information and exclude false positives.
  • ant: finds errors reported by Apache Ant.
  • bjam: finds errors reported by the Boost variant of jam.
  • clang: finds errors reported by the Clang C frontend for LLVM.
  • gcc: finds errors reported by the GNU Compiler Collection.
  • make: finds errors reported by GNU make.
  • maven: finds errors reported by Apache Maven version 1, 2 and 3.
  • msbuild: finds errors reported by Microsoft MsBuild.
  • nant: find errors reported by: NAnt.
  • visual studio: finds errors reported by Microsoft Visual Studio tools, such as compilers and linkers.
  • Xcode: finds errors reported by Apple Xcode.
Post-processors for other tools may be plugged in as desired.

The information extracted in this way is presented directly in the build summary so there is no need to trawl through build logs.


An automated build server gathers valuable data about your builds over time. Pulse makes this data available in the form of graphical reports. These reports show the frequency and success rates for you builds, and illustrate build trends over time. For example, reports show the number of test cases run with your build day-by-day. Using this build telemetry, you can see at a glance the progress of your test suite.

real time build logs

Not sure what your continuous integration server is up to? Wonder no longer with real time build logs. See the tail of the build log update in real time, even when the build is running on a remote agent! Tweak the number of lines shown and the update interval to see just what you need.

build controls

Pulse allows you to view and control build activity on your server. Builds in progress can be viewed via the web interface, as well as build queues. Build management features include:

  • build progress view: view up-to-date build status as the build executes.
  • view build queues: view all queues in the Pulse build engine.
  • examine real time build logs: view build output in real time (see above).
  • terminate builds: cancel a running build via the web interface.
  • specify timeouts: specify an optional timeout for each of your projects.

build history

Pulse stores a full history of all builds for your project for as long as you choose. Build results and working directories can be purged according to rules you specify to save storage space. With the build history you can:

  • browse the build history: browse through historical build results using the web interface.
  • filter history: filter historical results by their state.
  • browse working copy snapshots: via an AJAX powered web interface.


Pulse gives each developer their own configurable view of the Pulse server. This allows developers to quickly find the information relevant to them. Users have:

  • a configurable home page: where they can view projects of interest, changes to those projects and your latest changes.
  • build view preferences: controlling how build information is displayed.
  • individual subscriptions: providing control of build notifications.
The way each developer configures their dashboard can also be leveraged in other tools such as Stethoscope, the Pulse Windows system tray client.

project groups

Larger Pulse installations can contain many projects. Pulse allows you to organise these projects into logical groups by assigning the projects labels. The groups are used in the Pulse web interface to display the related projects together. You can also choose to show groups on your dashboard, and subscribe to RSS feeds for builds in a specific group.


All continuous integration servers support build result notifications, but in many cases they become useless as there is no way to separate signal from noise. Too many notifications are sent, leading developers to either waste time working through them or just ignore them altogether. What's more, different developers like to be notified of different things. For these reasons, Pulse gives every developer their own notification preferences via individual subscriptions.

To give developers full control, subscriptions are based on a powerful condition mechanism. For example, you can choose to be notified of:

  • all failed builds,
  • all builds including new changes,
  • all builds including new changes by you where the build state changed,
  • all builds where the state changed from ok to broken.
You can even combine these conditions in arbitrary ways by writing your own condition as a boolean expression!

predictable url scheme

As of version 2.0, the Pulse web interface uses a human-readable and predictable URL scheme. Want to see build 5 of project foo? Just go to:

From any page you can easily guess the URLs of related pages and jump around.

The URL scheme also supports the powerful notion of virtual build ids. This allows you to construct links to, for example, the artifacts for the latest successful build:


built-in documentation

The Pulse configuration interface includes built-in documentation for all forms and wizards. Just pop-out the documentation frame beside the form while you fill it in. Reference documentation is also included for hand-written pulse files, if you choose to use them, based on the installed set of plugins.

take responsibility for projects

When the build breaks, action needs to be taken to fix it. Developers on the team need to know who is looking into the problem. Pulse allows you to communicate this by taking responsibility for a project. When you take responsibility, you can optionally leave a comment letting your team know what you are investigating. The responsible user and their comment is displayed on the project's home page and on status pages for all builds of that project, so team members won't miss it. When you're done fixing the build, you can clear your responsibility, or have Pulse automatically clear it for you on the next successful build.

comment on builds

If you spend time tracking down the subtle reasons for a build failure, you wouldn't want those details forgotten by time. You also wouldn't want a team mate to waste their time repeating the same diagnosis! To prevent these scenarios, Pulse allows you to leave comments on build results. These comments are displayed prominently on the build status page, where your team mates will see them.

templated configuration

Pulse includes a unique templated configuration system. This allows you to define all common configuration in project (or agent) templates, and inherit that configuration for multiple projects. This powerful feature eliminates a lot of the duplication commonly found in continuous integration setups, making your installation easier to maintain over time.

Common uses for templates include:

  • Defining standard project setups for your organisation. If all your teams use Subversion and Ant, there is no need to define that for every single project.
  • Defining similar builds of the same code. The configuration for a continuous and nightly build of the same codebase is practically identical and should be shareable.

automatic agent upgrades

Maintaining a build farm can require a lot of maintainance. The last thing you need is to manually upgrade every single agent in your farm. That's why Pulse supports automatic agent upgrades. Simply upgrade your master server, and it will automatically upgrade each agent. The agents are immediately ready to start building again!

automatic configuration backups

The time invested in configuring your continuous integration server is automatically protected by Pulse via automated backups. Out-of-the-box Pulse will snapshot your configuration daily at 5am. You can also update this schedule to suit your own preferences using a cron expression.

agent utilisation statistics

Each build agent has a "statistics" tab that lists various statistics for the agent. These include the number of recipes the agent executes each day and how long the average recipe keeps the agent busy. Statistics are also shown for agent utilisation, including a pie chart that makes them easy to visualise. This allows you to see if you are getting the most out of your agent machines.

supported databases

When you evaluate Pulse, you will probably choose the simple option of the embedded database. When it comes time to deploy, however, Pulse includes support for both MySQL and PostgreSQL. These proven database systems come with a wealth of tools for management, making administration of your setup easier.

Even the migration step is easy: you can move your evaluation setup over to a production database by following a simple wizard.

flexible build core

The core engine of Pulse is not baised to any one build tool or environment. In fact, all specific tool support in Pulse is added by configuration of a small set of core components. Thus where specific tool support is not available, the same effect can often be achieved simply by dropping down to these core components and configuring them appropriately.

As an example, support for a specific build tool like make is built upon a core command that can be used to run any tool, and a regular expression post-processor that extracts useful information from the build output. The same effect is quite easily achieved by specifying appropriate command arguments and regular expressions to these core components.

This flexibility is hidden by default for simplicity, but is always available for projects with custom requirements, giving the best of both worlds.

plugin system

Continuous integration servers by their nature need to integrate with many different build tools and external systems. Pulse supports many tools out-of-the-box, but where there is no existing support we allow plugins to fill the gap.

Plugins are automatically synchronised between the master and other machines. This allows you to manage plugins on the master and have your agents automatically update themselves. Developer tools installations can also be synchronised automatically.

Importantly, the plugin system has been designed to make writing a plugin as simple as possible. First of all, the system is based on a standard OSGi core, allowing you to leverage existing tools and knowledge. Further, Pulse takes care of all the user interface and persistence details - allowing the plugin author to concentrate on more important things. This means plugins are integrated consistently into the web interface and templated configuration system without the plugin author needing to write a single line of CRUD code.

remote api

Pulse can be integrated and extended via a remote API implemented with XML-RPC. You can configure, monitor, control and extend your Pulse server using the programming language of your choice. The remote API allows:

  • simple integration: because it based on XML-RPC. No IDL or descriptors are required meaning you can just start coding and controlling Pulse.
  • full configuration: all aspects of configuration to be edited, even configuration contributed by plugins.
  • project monitoring: list all projects, check project status and retrieve build results for a project.
  • project control: pause/resume project builds or trigger a build from an external source.
  • agent control: disable/enable agents or check their status from an external system.
  • server control: shut down the Pulse server.

repository browsers

The Pulse web interface supports linking directly to changelist, file and diff views in the following repository browsers:

If support for your viewer doesn't exist you can create a custom viewer and define the URLs in terms of changelist properties.

issue trackers

Each time you fix a bug, you diligently add the bug ID to your commit message. You can configure Pulse to recognise those IDs and link them straight to your bug tracker! Out-of-the-box support is available for:

In fact, the support for adding links to commit messages is extremely felxible. Using simple regular expressions you can easily link to any external system.

role-based security

You can control access to your Pulse server using role-based security. Users are organised into groups and assigned privileges to those groups. Permissions are assigned both for server level operations and project- and agent-specific actions. Optionally, you can allow anonymous access so that guest users can browse build results.

You can even choose to allow users to sign up themselves as well as link Pulse to your LDAP server for authentication.

project and agent ACLs

As of version 2.0, Pulse supports fine-grained permissions set specificly for each project and agent. This allows you to control individual actions for each project and agent on an instance-by-instance basis.

It is also possible to configure view permissions for these instances, so some projects or agents may not be visible to some users at all.

Special groups for all and anonymous users allow you to assign permissions virtually. For example, your server may allow anonymous access but only to view public projects.

LDAP integration

User management couldn't be simpler for those of you already using LDAP authentication. Pulse can optionally authenticate users via LDAP and you can choose to have users automatically added to Pulse if they authenticate successfully via LDAP. It is even possible to integrate your LDAP groups by creating matching Pulse groups.

This support works with leading LDAP servers such as OpenLDAP and Active Directory.