New tcWebHooks release for TeamCity 9.1

Posted on July 29, 2015 Updated on March 18, 2016

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 https://github.com/tcplugins/tcWebHooks/releases

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 September 23, 2014

Introducing a new payload format called Tailored JSON in tcWebhooks version 0.9.27.61

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.

Building tcWebHooks custom parameters from teamcity build parameters

Posted on September 22, 2014 Updated on September 22, 2014

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

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

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

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.

Download the 0.9.26.60 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.

Integrating TeamCity with Slack.com using WebHooks

Posted on August 15, 2014 Updated on December 7, 2017

Update: Since version 1.1 of tcWebHooks, this  is now much simpler. See A better way of integrating TeamCity with Slack.com using WebHooks

Here is a quick example of how to integrate slack.com with TeamCity using the tcWebHooks plugin.

The first three messages were posted using the first example XML configuration below. The last two are more elaborate and utilise the second XML snippet.

Step by step

1. Create a new integration in Slack by going to the “Integrations” page.
2. Scroll to near the bottom and click on the “Incoming WebHooks” button.
3. Choose a channel to post into and click “Add incoming webhook”. A new integration should be created.
4. Find the section entitled “Your Unique Webhook URL” copy the URL underneath it including the Token at the end.
5. Switch to your teamcity web page and create a new WebHook.
6. Paste in the webhook URL from step 4 into the webhook config.
7. Choose Name Value Pairs payload format and select your trigger events. I suggest only selecting Successful and Failed. Otherwise you will fill your Slack channel with too many events. You may only want to choose when a build changes state to further reduce noise.
8. After you’ve saved your webhook config, you need to add the Slack specific payload options by editing the WebHooks configuration file on the TeamCity server. In TeamCity 8 it will be located at: $HOME/.BuildServer/config/projects/<your_project_name>/pluginData/plugin-settings.xml
9. Find your newly created WebHook and add the following block of XML before the </webhook> tag.

<parameters>
    <param name="payload" value="{&quot;text&quot;: &quot;${buildName} &lt;${buildStatusUrl}|build #${buildNumber}&gt; triggered by ${triggeredBy} has a status of ${buildResult}&quot;}"/>
</parameters>

The above XML snippet shows a simple message. Below is a more sophisticated example showing the use of the attachment JSON field to show a coloured bar and heading text on the message.

<parameters>
   <param name="payload" value="{  &quot;text&quot;: &quot;All your build failures are belong to us&quot;, &quot;attachments&quot;: [ { &quot;fallback&quot;: &quot;${buildName} &lt;${buildStatusUrl}|build #${buildNumber}&gt; triggered by ${triggeredBy} has a status of ${buildResult}&quot;, &quot;text&quot;: &quot;${buildName} &lt;${buildStatusUrl}|build #${buildNumber}&gt; triggered by ${triggeredBy} has a status of ${buildResult}&quot;, &quot;color&quot;: &quot;danger&quot; } ] }"/>
</parameters>

A more complete example

This shows two full webhook XML configurations so you can see the parameter tag in context. If you look closely, you’ll see the first one only applies to build failures, and the second one only applies to build success messages. That is how you can display a different colour and message for different build results.

<?xml version="1.0" encoding="UTF-8"?>
<settings>
  <webhooks enabled="true">
     <webhook url="https://<your_slack_url>.slack.com/services/hooks/incoming-webhook?token=<your_token_here>" enabled="true" format="nvpairs">
      <states>
        <state type="buildSuccessful" enabled="false" />
        <state type="buildInterrupted" enabled="false" />
        <state type="responsibilityChanged" enabled="false" />
        <state type="buildStarted" enabled="false" />
        <state type="buildFailed" enabled="true" />
        <state type="beforeBuildFinish" enabled="false" />
        <state type="buildFixed" enabled="false" />
        <state type="buildFinished" enabled="true" />
        <state type="buildBroken" enabled="false" />
      </states>
      <build-types enabled-for-all="true" enabled-for-subprojects="true" />
      <parameters>
        <param name="payload" value="{  &quot;text&quot;: &quot;All your build failures are belong to us&quot;, &quot;attachments&quot;: [ { &quot;fallback&quot;: &quot;${buildName} &lt;${buildStatusUrl}|build #${buildNumber}&gt; triggered by ${triggeredBy} has a status of ${buildResult}&quot;, &quot;text&quot;: &quot;${buildName} &lt;${buildStatusUrl}|build #${buildNumber}&gt; triggered by ${triggeredBy} has a status of ${buildResult}&quot;, &quot;color&quot;: &quot;danger&quot; } ] }"/>
      </parameters>
    </webhook>
    <webhook url="https://<your_slack_url>.slack.com/services/hooks/incoming-webhook?token=<your_token_here>" enabled="true" format="nvpairs">
      <states>
        <state type="buildSuccessful" enabled="true" />
        <state type="buildInterrupted" enabled="false" />
        <state type="responsibilityChanged" enabled="false" />
        <state type="buildStarted" enabled="false" />
        <state type="buildFailed" enabled="false" />
        <state type="beforeBuildFinish" enabled="false" />
        <state type="buildFixed" enabled="false" />
        <state type="buildFinished" enabled="true" />
        <state type="buildBroken" enabled="false" />
      </states>
      <build-types enabled-for-all="true" enabled-for-subprojects="true" />
      <parameters>
        <param name="payload" value="{  &quot;text&quot;: &quot;All your build successes should to be celebrated&quot;, &quot;attachments&quot;: [ { &quot;fallback&quot;: &quot;${buildName} &lt;${buildStatusUrl}|build #${buildNumber}&gt; triggered by ${triggeredBy} has a status of ${buildResult}&quot;, &quot;text&quot;: &quot;${buildName} &lt;${buildStatusUrl}|build #${buildNumber}&gt; triggered by ${triggeredBy} has a status of ${buildResult}&quot;, &quot;color&quot;: &quot;good&quot; } ] }"/>
      </parameters>
    </webhook>
  </webhooks>
</settings>

There is a full list of the variables available.