features
Pulse boasts all the features you expect of an fully featured automated build server, along with some that are rarely found in competing systems. The Pulse philosophy of working with the user their way drives these unique features:
- Build any project: run arbitrary commands or use support for ant, make, maven, maven2 or Xcode.
- Distributed builds: more than just remote builders, Pulse supports multi-platform and parallel testing across multiple agents controlled from a single master.
- Personal builds: submit your changes to Pulse for testing before you commit them to source control.
- Reports: view graphical reports of build history and trends for your project.
- Capture build artifacts: files, directories, HTML reports. Filter collected files using wildcards.
- Extract information: find errors and warnings with regular expressions or built in support for ant, make, maven, maven2 and Xcode.
- SCM server support: for CVS, Perforce and Subversion. Trigger builds on change, view changes between builds, tag built revisions, browse your repository.
- Build notifications: via email, Jabber IM, RSS and the Windows system tray. Each user controls their own notification preferences. Create your own notification templates to customise messages.
- Flexible scheduling: trigger builds on SCM server change, a Cron-like schedule, via the remote API or manually via the web interface.
- Build history: browse and filter your project's build history, including working directories. Cleanup historical builds using flexible cleanup rules.
- Test reporting: test results are a first-class part of the build result. Test results are read from JUnit, TestNG, CppUnit and OCUnit. or compatible reports.
- Flexible projects: choose simple configuration via the web interface or version your project configuration in your SCM server.
- Project groups: organise your projects into logical groups to manage larger installations.
- Build specifications: each project can have multiple specifications for different types of builds (e.g. continuous integration, nightly packages).
- Full web interface: setup, configure and monitor your Pulse server. Build a project without editing a single text file.
- Build controls: view build queues and builds in progress. Set build timeouts or manually terminate a running build.
- Real time build logs: auto-updating real time build logs for instantaneous feedback, even for remote builds!
- User dashboard: users have their own, configurable view of the Pulse server.
- Customise build information: customise the build information you see by dragging and dropping available columns.
- Project homepage: a single page overview of recent project activity, including builds, changes and statistics.
- Changelist isolation: an option to ensure each build contains at most one source code change.
- Role-based security: create user groups and assign server-wide and per-project privileges. Optionally allow anonymous access and/or signup.
- LDAP integration: authenticate and optionally add users via LDAP. You can even utilise LDAP group information.
- Linking: link from commit messages and/or changelists to other applications (e.g. your bug tracker, Fisheye).
- Resource dependencies: flexible configuration for external resources required by the build (e.g. libraries, compilers, runtimes, tools).
- Dependent projects: trigger builds of dependent projects when a project build completes.
- Incremental builds: manage large projects using incremental builds.
- Manual build properties: configure Pulse to prompt you for properties to be passed to manual builds.
- Local build: execute the Pulse build engine in your own working copy of the project.
- Remote API: monitor, control and extend your Pulse server remotely via XML-RPC.
detailed feature list
build any project
Pulse can build anything that can be built from a command line. Unlike other build tools, Pulse provides first class support for executing arbitrary commands. This feature is the core of the Pulse continuous integration server on which all specific tool support is built. Pulse supports the following commands:
- executable: run arbitrary commands with set arguments and environment variables;
- ant: Apache Ant;
- make: build using GNU make (or a compatible make variant);
- maven: build using Apache Maven version 1;
- maven 2: Apache Maven version 2; and
- Xcode: build using Apple Xcode.
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!
personal builds
You can submit outstanding source code changes directly to Pulse for testing before you commit them to your SCMserver. This personal build feature allows you to diagnose and fix any failures without affecting the shared code base.
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!
reports
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.
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 captured and browsed through the web interface.
extract information
An automated build system that can tell you 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:
- 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.
- make: finds errors reported by GNU make.
- maven: finds errors reported by Apache Maven version 1.
- maven 2: finds errors reported by Apache Maven version 2.
- Xcode: finds errors reported by Apple Xcode.
The information extracted in this way is presented directly in the build summary so there is no need to trawl through build logs.
SCM integration
Pulse supports CVS, Perforce and Subversion. Integration with these SCM servers provides:
- trigger on change: trigger a build when a change is submitted to the SCM server.
- 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.
- SCM browsing: browse your Pulse project's view of the SCM server.
build notifications
Pulse can notify you when a build has completed via email (plain text or HTML), Jabber instant messaging, an RSS feed or a Windows system tray client (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).
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.
flexible build scheduling
Pulse supports a variety 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).
- manual triggers: schedule a build manually via the web interface.
- dependent 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 history
Pulse stores a full history of all builds for your project for as long as you want. The build history includes both the build result and the working directory for the build. 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 and build specification.
- browser working directories: via an AJAX powered web interface.
- specify flexible cleanup rules: for build results and working directories independently as well as specify multiple cleanup rules based on result state and result age (measured in builds or days).
testing
If you are serious about continuous integration 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 by Pulse and reported through standard notification rules. Pulse has first-class test support that includes:
- easy integration: with any testing library that can produce a JUnit-like XML report.
- 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.
projects
A project in Pulse represents a single code line that you want to build. Multiple types of projects are supported. For simple requirements, ant, make, maven, maven 2 and Xcode projects can be configured via the web interface. You can also choose to create a Pulse file to describe how your project is built. This level of support for projects means that:
- simple things are simple: if you just want to get a simple project up and running, you can configure it completely via the web interface using the Add Project Wizard.
- powerful things are possible: via Pulse file projects which allow complete access the full power of Pulse.
- the upgrade from simple to powerful is clear: start out with a simple project, then convert it to a Pulse file project when you are ready.
- project files can be managed: the Pulse file can be checked in to your SCM server and versioned with your project source code. This allows you to maintain the configuration across multiple branches and releases.
project groups
Larger Pulse installations can contain many projects. Pulse allows you to organise these projects into logical groups. 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.
build specifications
Pulse doesn't restrict you to building each project one way. You can specify multiple build specifications for each project for different types of builds, and trigger these specifications according to their own schedule. For example, you might run quick testing builds every 15 minutes and full acceptance tests every night. You can define:
- multiple recipes: define different recipes for building your project in the project's Pulse file.
- independent triggers: where each specification has it's own set of triggers, and can be triggered individually via the web interface or remote API.
- build timeouts: each build specification can optionally have a timeout specified.
full web interface
Pulse is set up and configured completely via the web interface. From the point you install the Pulse package to your first project build, you do not have to edit a single text file. The only text file configuration in Pulse is the optional Pulse file, which enables you to store project configuration details in your SCM system along with your source code. The web interface includes a:
- setup wizard: set up or upgrade your Pulse server using a simple to follow wizard.
- add project wizard: add new projects with a three-step wizard.
- configuration view: all server, agent and project configuration is controlled via this web interface.
- view messages: server error and warning messages are available through the web interface eliminating the need to dig through log files.
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 below).
- terminate builds: cancel a running build via the web interface.
- specify timeouts: specify an optional timeout for each of your project's build specifications.
real time build logs
Not sure what your automated build 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.
dashboard
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.
- individual preferences: providing control of Pulse user interface and notification preferences.
customise build information
Build result reporting is a fundamental feature of the Pulse web interface. Pulse allows you to customise your view of this critical information by allowing you to choose the fields you are most interested in on any view. You can even reorder how these fields appear within a table using a simple drag and drop interface.
project homepage
Each project build by the Pulse continuous integration server has its own project home page. This is the central location for all recent activity for that project including:
- current build: the current build result summary is shown directly on the home page.
- recent builds: the latest 10 build results are summarised for you.
- recent changes: view the most recent 10 changes submitted to the project's SCM server.
- project statistics: simple metrics show how healthy your project has been over time.
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!
role-based security
You can control access to your Pulse server using role-based security. Users can be organised into groups and assigned privileges to those groups to allow:
- server administration: giving full control over the Pulse server.
- per-project administration: allowing configuration and build trigger access on a per-project basis.
- all-project administration: allowing administration access for all 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.
repository hyperlinking
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! You can also link from changelists to external repository viewers such as Fisheye, P4Web, Trac and ViewVC. Links are provided to view change information, download/view a file at a given revision and the diff view for a changed file.
resource dependencies
Resources dependencies such as 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 variables.
- 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).
dependent projects
Breaking projects down into components can be a great way to organise and streamline your builds. Pulse supports dependent builds with a special kind of build trigger. When a build of one project completes, you can kick off a build of a dependent project. This trigger can be filtered based on the build result, for example, you can make sure the trigger only fires after a successful build.
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.
manual build properties
Once you have Pulse running your automated builds, a natural next step is to build a 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 build specifications to prompt for property information when they are triggered.
local build
Pulse has the unique ability to execute a build with a developer's own working copy. By installing the Pulse local build engine on their workstation, any developer can build a Pulse file project locally. Using this feature you can:
- test configuration changes: to your project's Pulse file before checking the file in to your SCM server.
- repeat a build: exactly as it is executed by Pulse in your own workspace to debug build problems.
remote api
Pulse can be integrated and extended via a remote API implemented with XML-RPC. You can 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.
- 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.
- server control: shut down the Pulse server.
