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.

8 thoughts on “New tcWebHooks release for TeamCity 9.1

    Mattias said:
    November 4, 2016 at 12:04

    I just downloaded and testad the tcWebHooks plugin(0.9.x) to see if I could post to Microsoft Teams, also tested with I get a problem though, the return codes are 403 from and 400 from Microsoft Teams.
    Do you have any tips on what I did wrong?

      netwolfuk responded:
      November 4, 2016 at 13:06

      Hi Mattias.
      I’ve noticed that has started returning weird response codes recently.
      For that reason I added the local test page in the new 1.1 alphas. It is located on your teamcity server at /webhooks/endpoint.html
      The 1.1 versions are quite reliable. If you have a test teamcity system you could try that or a few people are running those versions on their production servers.
      I don’t know much about MS Teams, but 403 means Forbidden. Perhaps Teams is doing NTLM authentication to your browser which tcWebHooks does not currently support.
      If you can find a page on Teams that is not access controlled you could try that URL. Alternatively, if you can find a way to access Teams using Basic Authentication, you could configure BasicAuth with the latest tcWebHooks 1.1 release too.

    Mattias said:
    November 7, 2016 at 09:40

    Well, the url I am trying to use is based on a incomming webhoow integration and is not access controlled.
    It gives me a http status 400 but I can’t seem to figure out what to do about it, I did install the alpha 8 and the testurl works, to bad, would be nice to get it to work.

    Mattias said:
    November 7, 2016 at 09:57

    If you want to I can send you the full url that is supposed to be called, but i wil have to do it private, since I don’ät want to give it to the public.

    Marco said:
    December 27, 2016 at 17:03

    Mattias, where you able to solve this issue? I’m facing the same issue. I tried changing the target URL from requestbin to /webhooks/endpoint.html but I’m getting another error “Unexpected error: the trustAnchors parameter must be non-empty”.

      netwolfuk responded:
      December 27, 2016 at 17:12

      Are you using the full url with http:// or https:// at the start?

        Marco said:
        December 27, 2016 at 21:50


        netwolfuk responded:
        December 27, 2016 at 22:00

        I had a quick look earlier, and would guess that the Java process running TeamCity does not trust the certificate being presented by the webserver hosting TeamCity. Or, the java process cannot find the trust store.

        What OS are you running TeamCity in?
        What Java (version and vendor) are running TeamCity on?
        Are you running SSL in Tomcat? Or fronting TeamCity with something else (like Apache or nginx)?
        Which version of tcWebHooks are you running?
        Are you running a self-signed SSL certificate or one bought from an SSL provider?

        Have you seen this?

        Can we continue the discussion on github?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s