New tcWebhooks payload format : Tailored JSON

Posted on

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.

Tailored JSON via the body parameter

Advertisements

26 thoughts on “New tcWebhooks payload format : Tailored JSON

    Benedek Farkas said:
    November 4, 2014 at 16:53

    Hi! I’ve just started playing with the “Tailored JSON” message format for sending build notifications to HipChat (API v2) and it’s working great.
    What I would like to achieve with it is to send the build results (e.g. why the build failed, as it can be seen under /viewLog) to HipChat directly, because would like to avoid the devs having to have credentials for more systems, TC in this case. As far as I can tell, it’s not possible at the moment.
    I’m not sure if it’s feasible, but the build log/overview could be a useful addition to the currently available set of object variables as listed in one of your previous blogposts (https://netwolfuk.wordpress.com/2013/08/31/custom-templates-and-branches-in-tcwebhooks). What do you think?

      netwolfuk responded:
      November 6, 2014 at 05:36

      That’s a nice idea. I wonder if there are already some TeamCity parameters which are already available.

        Benedek Farkas said:
        November 18, 2014 at 12:37

        I didn’t find anything useful for that yet. :/

        netwolfuk responded:
        November 24, 2014 at 06:51

        Yes. Neither did I. I’ll add a ticket for it on Github.

    TataBlack said:
    July 16, 2015 at 11:35

    Hi there. Is it possible to have two webhooks, one for failed and one for successful builds, with a different payload? Basically, I’d like to have green-colored messages for successes, and red for failures. At the moment, both webhooks seem to share the same webhook.body parameter. Thanks!

      netwolfuk responded:
      July 20, 2015 at 10:57

      Thanks for your comment. I have built a new version for you to test which parses the template twice. This means that variables can now be nested.

      1. Download from here: https://teamcity.jetbrains.com/repository/download/WebHooksAndOtherPlugins_TcWebHooksBranch09xX/531188:id/tcWebHooksPlugin-0.9.33.67.zip
      2. Create two Configuration parameters in your build in teamcity, as per above. I created them at the project level so that all builds can use them.
        I created mine as webhook.body.failure and webhook.body.success
      3. Create two webhooks with format tailoredjson. One for failure, and one for success and configure them with the appropriate build events.
      4. Edit the ~/.BuildServer/config/projects/__project_name__/pluginData/plugin-settings.xml file and add references to the relevant Configuration Parameter, but remember to remove the “webbook.” from the name because tcWebhooks strips those out. Mine look like this:

      The only part should need to add is a section inside each webhook for the parameters. eg,
          <parameters>
            <param name="body" value="${body.success}" />
          </parameters>

      For example, this is what my webhooks look like:
        <webhook url="http://your_webhook/url" enabled="true" format="tailoredjson">
          <states>
            <state type="buildBroken" enabled="false" />
            <state type="buildInterrupted" enabled="false" />
            <state type="buildFixed" enabled="false" />
            <state type="buildSuccessful" enabled="false" />
            <state type="responsibilityChanged" enabled="false" />
            <state type="buildFinished" enabled="true" />
            <state type="buildFailed" enabled="true" />
            <state type="beforeBuildFinish" enabled="false" />
            <state type="buildStarted" enabled="false" />
          </states>
          <build-types enabled-for-all="true" enabled-for-subprojects="true" />
          <parameters>
            <param name="body" value="${body.failure}" />
          </parameters>
        </webhook>
        <webhook url="http://your_webhook/url" enabled="true" format="tailoredjson">
          <states>
            <state type="buildBroken" enabled="false" />
            <state type="buildInterrupted" enabled="false" />
            <state type="buildFixed" enabled="false" />
            <state type="buildSuccessful" enabled="true" />
            <state type="responsibilityChanged" enabled="false" />
            <state type="buildFinished" enabled="true" />
            <state type="buildFailed" enabled="false" />
            <state type="beforeBuildFinish" enabled="false" />
            <state type="buildStarted" enabled="false" />
          </states>
          <build-types enabled-for-all="true" enabled-for-subprojects="true" />
          <parameters>
            <param name="body" value="${body.success}" />
          </parameters>
        </webhook>

    TataBlack said:
    July 20, 2015 at 16:16

    Thanks! I’ll get in touch with my TeamCity admin and see whether we can get this running. I’ll keep you posted. 🙂

    […] 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 […]

    hakibush said:
    September 7, 2016 at 10:19

    Hi
    I have configured the TeamCity webhook plugin with a tailored JSON (webhook.body parameter).
    The webhook notification is sent to the remote endpoint but without username/password basic authentication credentials.

    I have tried to add username/password to the URL but it didn’t work. The notification has arrived without the basic authentication header:
    http://username:password@10.130.175.167:8080/new-build-notification

    How can I set the username/password for this webhook?
    Is there an Administration UI page for that?

    How can I find out the version of the TeamCity webhook plugin that is installed on our corporate Team City?

    Thanks
    Ofer

      netwolfuk responded:
      September 7, 2016 at 10:48

      Hi Ofer.
      To use the basic authentication feature recently added, you need to edit the project’s plugin configuration file on the TeamCity server. There is no UI yet sorry.

      You need to add an “auth” block like in these examples: https://github.com/tcplugins/tcWebHooks/wiki/Advanced-Editing-of-tcWebHooks-configuration

      Authentication was added in versions 0.9.80.83 and 1.1-alpha5.81.121

      The version of the plugin is available from the Plugins section of the TeamCity administration pages eg, http://teamcity_server/admin/admin.html?item=plugins

      I understand not everybody has access to the admin screens in TeamCity, so I have added it to webhook’s editing page in the latest 1.1-alpha version which I expect to release this week. This doesn’t help you much today though. Sorry.

        Ofer Yaniv said:
        September 7, 2016 at 12:43

        Hi

        Thank you very much for your prompt response.

        I would definitely ask our corporate IT to upgrade to version 0.9.80.83.
        Do we need to upgrade the TeamCity server itself to an higher version to enable this feature?

        For some reason, I don’t see plugins information at http://teamcity_server/admin/admin.html?item=plugins

        After the manual update of plugin-settings.xml, would the “auth” section be overwritten by further updates of the webhook config at the UI?

        Would it be possible to update 0.9.80.83 so it would support username/password specification at the URL. Like: http://username:password@10.130.175.167:8080/new-build-notification ?

        Thanks
        Ofer

        netwolfuk responded:
        September 7, 2016 at 16:36

        Version 0.9.80.83 should work on any version 9.x and 10.x of TeamCity. Which version of TeamCity are you using and I can test?

        Can you see the Administration link near the top right corner of the TeamCity page? If you get onto the server, you can see the version of the plugin by looking in .BuildServer/plugins/ The tcWebHooks plugin zip file will have a version number in it. eg, tcWebHooksPlugin-0.9.80.83.zip

        Editing the webhook in webhook UI does not remove the auth block. It is persisted through edits perfectly fine even though you can’t see it in the UI.

        Supporting editing of username/password is a good idea. But storing it in the URL is not a great idea because it would be visible to people in the logs and UI.
        I will have a think about extracting it from the URL if it’s there and creating/updating the “auth” block or will just add an auth tab to the UI and let you enter it there.
        I will make sure I update both the 0.9.x.x version and the 1.1.x.x version branches.

        Ofer Yaniv said:
        September 8, 2016 at 14:57

        Hi

        Thank you very much for your prompt response and kind support.

        I have successfully installed and configured Version 0.9.80.83 on a private TeamCity instance.
        I have manually configured ~/.BuildServer/config/projects//pluginData/plugin-settings.xml on my private TeamCity instance with the username/password and it works great!

        Our corporate TeamCity is already running webhook plugin version 1.1.63.9 ( so we would probably not downgrade to 0.9.X versions ).
        Are you familiar with this version?
        I haven’t found it on the releases page: https://github.com/tcplugins/tcWebHooks/releases/

        You have mentioned that the version that you expect to release this week would include a UI for the auth section. Is it 1.1-alpha7.122.138 ( released today )?

        Is there going to be a non-alpha version for the UI page soon (to be installed on the Corporate TeamCity)?

        Thanks
        Ofer

        netwolfuk responded:
        September 8, 2016 at 19:07

        All the 1.1 versions are alphas. You are running an old 1.1 alpha built from revision number 63 of the custom-templates branch (aka 1.1…)

        However it’s build number 9 in TeamCity which seems unlikely. I suspect your TeamCity admin person downloaded it from teamcity.jetbrains.com or built it themselves.

        I didn’t get a chance to do the UI changes last night because you indicated you wanted it in 0.9.x.x and I wanted to get the fixes out for the 1.1.x.x branch.

        You certainly don’t want to go from 1.1 to 0.9 because all the template features are new in the 1.1 branch.

        The alphas are all pretty stable. It seems you’re already running one, albeit a very old one.

        I will probably more likely get the ui done in 1.1 and then back port to 0.9 if people request it.

        Ofer Yaniv said:
        September 8, 2016 at 19:32

        Hi

        Thank you very much for your detailed response.

        Having the tailored JSON format is an excellent idea that has saved us significant effort and on-going maintenance of a TeamCity-specific plugin on our server side.
        This has simplified our architecture and improved our customer experience.

        Your professional help and kind approach is appreciated very much.

        Looking forward to the UI page at one of the coming 1.1 versions.

        Kind Regards,
        Ofer

    netwolfuk responded:
    September 8, 2016 at 19:41

    Thank you for your kind words and encouragement. I’m really glad it’s providing so much value. This is the kind of feedback that makes maintaining an open source project worthwhile.

      Ofer Yaniv said:
      September 17, 2016 at 11:00

      Hi

      Our corporate IT is going to upgrade to 1.1-alpha7.122.138 in order to have basic authentication support for this plugin.
      https://github.com/tcplugins/tcWebHooks/releases/tag/v1.1-alpha7.122.138

      The only issue is that we (as users) don’t have access to plugin-settings.xml on the remote TeamCity server.

      When can we expect have a 1.1.X plugin version that would introduce some method (simple UI) that would allow us (as users) to set the user credentials of our application webhooks?

      Thanks
      Ofer

        netwolfuk responded:
        September 19, 2016 at 12:52

        I hope to have something for you to test on your private TeamCity instance within the next week.
        Then you can validate that it works as expected and I can do a formal release for your TeamCity team to update to.

        netwolfuk responded:
        September 20, 2016 at 13:18

        I have a early release ready for testing. Please see https://github.com/tcplugins/tcWebHooks/issues/50

        Ofer Yaniv said:
        September 20, 2016 at 14:37

        Hi

        Thank you very much for the early release.

        We would test this on our dev instance and update.

        Thanks
        Ofer

    Ofer Yaniv said:
    September 21, 2016 at 06:40

    Hi

    We have tested the authentication UI at the latest plugin on our dev instance of TeamCity.

    It is working like a charm on first attempt!
    🙂

    Our dev teamcity is now integrated with our backend server orchestrating the entire DevOps cycle!
    Next step would be to install the latest plugin on our corporate production Teamcity.

    Thank you very much for your agile approach.
    This excellent plugin has saved us significant work & maintenance of a dedicated custom plugin for TeamCity (like we had to do with Jenkins… ).
    Appreciate this very much.

    ( At our use case, authentication is mandatory. We should not disable authentication… )

    Kind Regards,
    Ofer

    Jesper said:
    February 3, 2017 at 10:32

    Hello!

    Using e.g. a property webhook.body {“text”:”${buildStatusHtml}”} will produce a malformed JSON object, since the ${buildStatusHtml} property is unescaped. Is there any potential workaround for this? I am trying tcWebHooksPlugin 1.1-alpha8.140.143.

      netwolfuk responded:
      February 6, 2017 at 08:17

      Hi. Yes, you’re right. I didn’t really design that property to be used in JSON. The best work around is probably to build the string you want rather than using buildStatusHtml one. Thanks for raising the issue on github. Let’s continue the discussion there.

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s