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.

new tcWebHooks release. Proper support for TeamCity nested projects

Posted on Updated on

The alpha release from last week is now available as the main release.

This release includes the following new features.

  1. Proper support for TeamCity’s nested project structure. You can now choose if a webhook is inherited by child projects.
  2. ExtraParameters can now be templated in a similar way to the htmlStatusMessage field. This has come in handy for FlowDock integration.

Nested Project support

Webhooks can be inherited by subprojects
Webhooks can be inherited by subprojects

Previous versions of the tcWebHooks plugin did not support nested projects at all. A webhook was configured for a project and only builds in that project would fire them. This version adds support for webhooks to be inherited from parent (and higher) projects.

To enable the old behaviour, I also added control of that feature to the UI as “sub-project builds”. By default webhooks are inherited, but that inheritance can be disabled by deselecting the “All Sub-Project Builds” check box.

Extra Parameter templates

Prior to the latest release, additional parameters were static text only. This release adds the ability to template them in the same manner as the buildStatusHtml message Custom Templates detailed in a previous post.

Here is an example of their use for integration with FlowDock.

 <webhook url="https://api.flowdock.com/v1/messages/chat/your-api-key" enabled="true" format="nvpairs">
     <state type="buildFixed" enabled="false" />
     <state type="buildStarted" enabled="false" />
     <state type="buildBroken" enabled="false" />
     <state type="buildSuccessful" enabled="true" />
     <state type="buildFinished" enabled="true" />
     <state type="responsibilityChanged" enabled="false" />
     <state type="beforeBuildFinish" enabled="false" />
     <state type="buildFailed" enabled="true" />
     <state type="buildInterrupted" enabled="false" />
   <build-types enabled-for-all="false" enabled-for-subprojects="true">
     <build-type id="bt3" />
     <param name="content" value="${message}" />
     <param name="external_user_name" value="teamcity" />
     <param name="tags" value="${projectExternalId},${buildExternalTypeId},${buildResult},teamcity" />

These parameters will appear as part of the POST payload and have the ${variables} resolved as per the details in the previous post.

Download and feedback

As usual, please download and post any issues you find on the bugs page.