Don’t use Eclipse’s web viewer for Cobertura reports…

Posted on Updated on

… or Javadoc, or anything with frames.

It doesn’t appear to refresh correctly, and I was missing updates to my coverage.

Load them in a real browser instead.


Custom Templates and branches in tcWebHooks

Posted on Updated on

New release available

There is a new release of the TeamCity WebHooks plugin (tcWebHooks –

  1. Adds branch details to the top level of the WebHook Payload Content object (fixes missing branch info in the Name/Value Pairs format).
  2. Fixes an incorrect link on the WebHooks tab of a build.

Download it from SourceForge

Feature Branches and tcWebHooks

I’ve spent the last few evenings working through various issues with the branch support I added a few releases ago.┬áBecause I don’t use a VCS that TeamCity supports for branch building, I have never had the opportunity to thoroughly test the feature.

With the help of Jeff, we worked through a number of issues with the Name/Value Pairs (nvpairs) format and my handling of the Branch interface that was added in TeamCity 7.0

The main problem was that the Branch object was being added to the WebHookPayloadContent, but as a child object. Therefore, structured payload formats like JSON and XML were serialising out the contents of the child object correctly, but the nvpairs format was not. It appears that most users are using the nvpairs format. Especially those POSTing to the HipChat webservice endpoint.

As a result of these changes, I have added the following items to the payload object and they are serialised out for all payload formats at the top level.

  • branchDisplayName – A friendly name like “master” or “feature01”.
  • branchName – A name used internally by TeamCity. In my testing, it shows as “<default>” for the “master” and “feature01” for the “feature01” branch.
  • branchIsDefault – A Boolean (note the uppercase B), that can be null, true or false depending on whether the build has feature branches enabled (null if not), is the master (true) or a branch (false).

These names are gleaned straight from the “Branch” interface in the TeamCity OpenAPI. I note with interest that the actual TeamCity implementation has different names (myBranchName, myDisplayName), so the JSON payload actually looks like this.

  "branchName": "<default>",
  "branchDisplayName": "master",
  "branchIsDefault": true,
  "branch": {
    "@class": "jetbrains.buildServer.serverSide.impl.BranchImpl",
    "myBranchName": "<default>",
    "myDisplayName": "master"

The upshot is that the WebHookPayloadContent bean is what the custom templates use for building up the htmlBuildStatus message. That means that when configuring a custom message, you can only expect to resolve variables from this bean (using the getters). If value is not set for this instance variable, you will get “null” back. If the getter does not exist, you will get “UNDEFINED”.

A gotcha with the Branch object supplied by TeamCity

The Branch object and the new payload variables are completely dependant on TeamCity passing a useful Branch object to the sRunningBuild.
Please be aware that you will only get a sensible set of branch variables if all the following are true:

  1. You are running TeamCity version 7.1 or higher.
  2. The VCS that the build is built from has support for feature branches provided by TeamCity (currently in TC8 this is only GIT and Mecurial).
  3. You have configured feature branch support in your build so that TeamCity is aware that you have more than one branch that could potentially be used for versioning your build. For more information, please see:

If any of these are not correct, you will get null values for the new branch variables supplied by tcWebhooks.

A list of the object variables in the WebHookPayloadContent bean

As of tcWebHooks verion, you should expect the following to be available to the buildStatusHtml template engine.

Variable Name Example Value
projectId GitTestBuilds
message Build Git Test Builds :: Git Test Build has finished. This is build number 22, has a status of “success” and was triggered by Net Wolf
buildStatus Tests passed: 2
buildId 76
buildStateDescription finished
extraParameters null
buildInternalTypeId bt9
branchName feature01
comment null
class class webhook.teamcity.payload.content.WebHookPayloadContent
projectExternalId GitTestBuilds
agentHostname localhost
text Git Test Builds :: Git Test Build has finished. Status: success
buildExternalTypeId GitTestBuilds_GitTestBuild
buildResultPrevious success
projectName Git Test Builds
buildTypeId GitTestBuilds_GitTestBuild
triggeredBy Net Wolf
buildResult success
buildRunners [Maven]
agentOs Linux, version 3.2.0-51-generic
agentName Default Agent
buildName Git Test Build
buildFullName Git Test Builds :: Git Test Build
branchDisplayName feature01
buildResultDelta unchanged
projectInternalId project5
notifyType buildFinished
buildNumber 22
branchIsDefault false

tcPrettyEmail TeamCity plugin now supports STARTTLS

Posted on Updated on

A recent commenter on the blog mentioned that using a gmail address as the sender address from the tcPrettyEmail plugin was not working due to the fact that wants to use TLS.

I had a quick look through the javax.mail API docs and a browse over stackoverflow, and found that enabling STARTTLS support would be relatively simple. I’m using the spring mail wrapper because it’s bundled with TeamCity, and found that you can pass in extra options using a standard JavaProperties object.

So a few extra lines of code to support the extra tag in TeamCity’s main-config.xml file was all that was really needed to enable it.

While I was pushing a new version, I fixed a couple of missing image files that were causing messages to fail for some less common email message types.

The new version is uploaded to the sourceforge download page and the docs updated to include the new field.

The enable starttls, simply add an argument to the smtp tag (nested inside pretty-email) in main-config.xml. You will probably need to add your username and password to the file as well. Here is an example using gmail as the sender:

    <smtp host="" port="587" 
          from-name="Friendly Name" 
          starttls-enabled="true" />

For futher detail, please see the documentation.

New tcWebhooks bugfix release available

Posted on Updated on

A recent comment on my blog pointed out that the buildStatus field in the webhook POST payload was not accurate.

After some investigation, I noticed the the buildStatus does not get updated until after the build has been marked as “finished” by TeamCity. However, the build is not marked as finished until the plugins have run, so all builds were reporting themselves as “running”.

I have added a new field called buildResult, which gleans the result from the sRunningBuild object, rather than relying on the buildStatus returned by TeamCity.

Thanks to Lloyd for helping me work through the issues and testing. I have now uploaded a new jar to sourceforge.

I also spotted that one field in the JSON payload was incorrectly stating that the notification was for buildStarted when in fact it was buildFinished. This has now been corrected.

TeamCity WebHooks plugin beta available

Posted on Updated on

Announcing a beta release (version of a plugin for TeamCity which enhances TeamCity to provide WebHook functionality. With the tcWebHooks plugin installed, you can tell TeamCity to trigger a webhook POST request as build events occur.

WebHooks are configured on a project basis, and when events occur in the build process, a POST request is submitted to the URL. You can configure as many URLs as you like (within reason) and which events will trigger the request.

There is support for proxies in this version, and webhooks are configured in the TeamCity UI. There are a few outstanding items to tidy up, but the core functionality is working.

The project is on SourceForge at