Posting to Atlassian Stride from TeamCity

Posted on Updated on

Stride is the new collaboration and communication tool from Atlassian. It is the replacement to the old hipchat system which was one of the first chat programs that tcWebHooks supported.

Stride has recently become available for public use and utilises an authentication protocol that tcWebHooks didn’t previously support.

The most recent 1.1 release of tcWebHooks now supports both basic and bearer authentication which allows posting to a Stride room.

Posting a message to a stride channel requires a specially formatted JSON payload. Working with the tcWebHooks community, we have developed a template which provides simple success and failure messages and I’m sure as more users come on stream we can make this more sophisticated. This is what it currently looks like in a Stride room.


tcWebHooks is a plugin for TeamCity which provides the ability to initiate post requests for events during the build lifecycle.

Posting to Stride is as simple as:

  1. Install the tcWebHooks and tcWebHooks rest API plugins into teamcity.
  2. Import the Stride template using the rest interface.
  3. Configure your stride room and create a webhook use the Stride template.

A better way of integrating TeamCity with using WebHooks

Posted on Updated on

I wrote a blog post in 2014 about how it’s possible to get tcWebHooks to send messages to slack. It turned out to be one of the more popular posts.

The good news is that in version 1.1 of tcWebHooks, it got whole lot easier.


  1. Install the latest tcWebHooks 1.1 (or higher) plugin into TeamCity.
  2. Create an incoming webhook in slack.
  3. Create a webhook in TeamCity and choose from one of the Slack payload formats
  4. That’s it!


Bundled Slack WebHook Templates

As of the time of writing (December 2017), there are two Slack specific webhook templates bundled with a tcWebHooks release.

1. The “ JSON templates” payload format has templates which produce a message in slack with some information about the build.


2. The “ Compact Notification” has templates which produce a more compact notification.


If neither of those are right for you, it’s possible to create your own template by either copying an existing one, or creating a new one.

WebHook Templates

A WebHook Template is a predefined payload that can be reused with multiple webhook configurations. I’ve prepared a few to get you started, but it’s very easy to modify them or create your own. The ones bundled with tcWebHooks include:

Creating or editing templates is accomplished using a WebUI built on top of the tcWebHooks REST API.  Further information about WebHook Templates is on the wiki.


TeamCity WebHooks plugin poll

Posted on Updated on

If you’re a tcWebHooks plugin user, could you please take a couple of minutes to post a comment on this poll?

I am trying to determine how much effort I should invest in supporting older versions of TeamCity, and where to focus future development.

There are some new features in TeamCity 10 which I would like to migrate to, and I am wondering how many tcWebHooks users would be affected by discontinuing support for versions 9.x and below.

Also, how tcWebHooks is being used, and what payload formats are popular.

Many thanks in advance for your time.

New tcWebHooks release for TeamCity 9.1

Posted on Updated on

The recent release of TeamCity 9.1 caused an issue with webhooks failing to be sent under certain specific conditions.
The Branch object supplied by TeamCity as part of an sBuild now contains references to the parent project, which then contain references back to the build which contains a reference to the Branch.

This creates a circular reference which prevented the Xstream library from serialising the webhook payload.

This would only present if one was running a build from a VCS that supported branches (Git or HG) and it was a non-master build (eg, feature branch) and the payload was XML or JSON.

I have worked around this by creating a simple bean and copying just the relevant parts of the branch to the bean which is then serialised in the webhook content.

I also found an issue with creating new webhooks in the _Root project. The “create webhook” message was sent to TeamCity when the webhook editing dialog closed, but the new webhook was never actually being created. This has now been resolved.

Currently, sourceforge is preventing me from adding new release files for download.
I therefore, think now is the time to move to GitHub for releases. The updated release (v0.9.35.72) can be downloaded from

As usual, any issues can be raised on GitHub or posted on the tcWebHooks bugs page.

Additional Feature: Double template rendering passes.

Messages passed to webhooks payloads containing ${variables} are now parsed twice. This means that custom messages can contain tcWebHook variables as requested in a comment on the blog. You can read more in the commit message.

New tcWebhooks payload format : Tailored JSON

Posted on

Introducing a new payload format called Tailored JSON in tcWebhooks version

This format only sends the contents of the “body” parameter as application/json. It is up to the user to define the content of the body parameter.

The easiest way to define the body is with a TeamCity build parameter called webhook.body as per the screenshot below.

Tailored JSON via the body parameter

Building tcWebHooks custom parameters from teamcity build parameters

Posted on Updated on

Custom Parameters are a feature in the tcWebhooks plugin, which allow one to send a custom string to the webhook endpoint made up of a template and variables.

Up until today, those variables have only included other values from the webhook’s payload. However, from now on it is also possible to use build paramters from the TeamCity build configuration. One now has access to the TeamCity build properties. These include properties defined by the build configuration, as well as env.*, teamcity.* and system.* properties.

An example is worth a thousand pictures

        <param name="aaa_param" value="TeamCity version ${system.teamcity.version} running as user ${env.LOGNAME}" />

This example parameter will add an item as per the table below.

Name Value
aaa_param TeamCity version 8.1.4 (build 30168) running as user netwolfuk

Using the TeamCity build parameters to create Custom Webhook Parameters

Additionally, any property beginning with the string “webhook.” will automatically be included in the webhook payload with the “webhook.” prefix removed. This allows custom parameters to be declared from the Teamcity build parameters rather than having to edit the webhooks plugin XML file. The above example could then be configured as per the following screenshot.

Screenshot from 2014-09-23 09:27:07
Download the version (or higher) from sourceforge to try it out.

The build parameters configuration in Teamcity is explained on the TeamCity configuration properties wiki page. More info about using tcWebHooks custom parameters is also available.

Triggering a webhook for every TeamCity build (aka using the _Root project)

Posted on

I was recently asked in the comments whether it is possible to add a webhook to trigger for all builds in all projects.

The answer is: yes, but you have to add it to the configuration manually.

The _Root project

In recent versions of TeamCity, a hierarchy was introduced for projects. This means there is now a “Root” project, which is referred to internally by TeamCity as “_Root”. All projects are descendants of the Root project.

When I added descendant project support for the tcWebhooks plugin, I deliberately didn’t allow configuration of the Root project, because it would be too easy to inadvertently add a webhook to every build on TeamCity, even if there are builds that are not your part of a team’s projects.

However, that logic is applied in the UI, not at the webhook triggering level. Therefore, if you configure a webhook in the _Root project XML file on the TeamCity server, it will add a webhook for every build on every project.


Edit ~/.BuildServer/config/projects/_Root/pluginData/plugin-settings.xml

Mine looks like this:

<?xml version="1.0" encoding="UTF-8"?>
  <build-report-tab title="Code Coverage" startPage="!index.html"/>
  <build-report-tab title="JavaDoc" startPage="!index.html" />
 <webhooks enabled="true">
  <webhook url="http://<webhook_end_point>" enabled="true" format="nvpairs">
    <state type="beforeBuildFinish" enabled="false" />
    <state type="buildFixed" enabled="false" />
    <state type="buildFailed" enabled="true" />
    <state type="buildSuccessful" enabled="true" />
    <state type="buildStarted" enabled="false" />
    <state type="buildFinished" enabled="true" />
    <state type="buildBroken" enabled="false" />
    <state type="responsibilityChanged" enabled="false" />
    <state type="buildInterrupted" enabled="false" />
   <build-types enabled-for-all="true" enabled-for-subprojects="true" />