The two main views in Pulse, the browse and dashboard views, now allow you to filter by health. All projects are shown by default, but you can trim your view to show only, for example, projects that are currently broken.

The filter drop-down is integrated into a toolbar that also includes the pre-existing layout controls for these views. Both the selected filter and layout can be saved.

Pulse now has built-in support for the MSTest unit testing framework from Microsoft. A new post-processor plugin parses the TRX reports produced by MSTest, integrating test results into your build.

The ability to communicate with team mates via comments has been extended with comments on agents. If you need to take down an agent for maintenance, you can leave an explanation for your users.

Both agent and build comments are also more visible than before. A small comment icon will appear in summary tables, with the comment shown on hover.

Properties may now be defined directly on agents. As with all properties these allow you to parameterise your builds.

Agent properties complement the existing, powerful, resource system. They provide a more direct way to handle simple parameterisation.

As with agents, the Pulse master now supports a resource repository. This allows powerful configuration of available resources on the master machine.

In particular, the master resource repository can be used to fine-tune the configuration of SCM commands run on the master. All SCM plugins that rely on an underlying command-line tool can be configured in this way.

Several improvements have been made to the intersection of change reporting and dependencies. Most importantly, changes to an upstream project are visible on downstream builds.

Further, you can now choose to be notified of downstream builds that are indirectly affected by your changes. This goes for both notifications sent via build hooks and those sent via your personal subscriptions.

Build notifications now support the attachment of build logs. If you opt-in to log attachments your emails will have an overall build log and a log for each stage attached.

As logs can be large and the most useful part is often at the end, you can choose to limit the attachments to a specified number of lines from the tails of each log.

Builds that have warning features detected now finish in a distinct warnings status. Previously these builds were marked as successful with some UI decoration to highlight the warnings. Builds in the new status are still perceived as healthy.

This change brings consistent treatment to these builds throughout the UI and the API. As an example, the build navigator now correctly highlights builds with warnings.