Updated TeamCity WebHooks plugin available

Posted on Updated on

Version 0.6.13.11 of the tcWebHooks plugin is available for download. It’s mainly a bugfix release and some tidy up of the user interface.

Fixes:
– Fix for newly created WebHooks not being persisted to plugin-settings.xml until re-edited.
– Plugin JSPs loaded using getPluginResourcesPath(), so plugin dir can be anything, and not hard-coded to “webhook”.
– webHookUrl form input style fix for linux (or large fonts in general). URL input field was too wide for div.

Features:
– WebHook blurb updated. A new link can be added to the “Further reading” section of the blurb by adding a <info> line to the <webhooks> section of the main-config.xml
– Enabled events are now listed in Tabs and Edit pages, eg. Build Started, Build Changed Status, Build Interrupted, Build Almost Completed, Build Responsibility Changed

Links:

More Info | Download | Install and usage docs

I welcome any and all feedback.

Advertisements

6 thoughts on “Updated TeamCity WebHooks plugin available

    Justin May said:
    September 14, 2009 at 18:50

    Hi, I just installed the 0.6.13.11 snapshot of your webhooks plugin and it’s working pretty well so far. I have just noticed, however that I never seem to get a status update notification when a build goes from ERROR to SUCCESS. But I always get a status update when a build status changes from SUCCESS to ERROR.

    And it this the proper place to make comments on your project? Or should I use sourceforge’s ticketing system?

    Thanks,
    Justin

    netwolfuk said:
    September 15, 2009 at 10:04

    Hi Justin.

    Looking at the JavaDocs, it implies that event is only called when a build goes from successful to failed. I suspect the event is on a per build basis, not on a build history basis.

    I wonder if I could manufacture a “status good” event when a build completes successfully. I guess I could have to look at the previous build status and see the current build is “fixed” in comparison.

    I was looking at using the sourceforge trac wiki for support requests, but it seems I had the wrong URL in the support page. Also, trac seems a bit cumbersome (eg, you need to be a sourceforge user to create a ticket).

    I have created a ticket for this bug.

    Justin May said:
    September 15, 2009 at 16:26

    Ahhh ok. I was thinking that the status change update was more of a red light/green light type of thing. But from the TeamCity docs it looks like I can just monitor the statusChange event for knowing when the build breaks, and the buildFinished finished event can be used to tell when the build is fixed again.

    I’m using this incredibly useful plugin on an auto-building demo system. Every night the system updates its source from SVN and recompiles it. I’m using tcWebHooks to tell my auto builder not to build if the build is broken. Thanks so much!

    netwolfuk said:
    September 16, 2009 at 18:50

    Yeah, the wording in the plug-in is misleading. I’ll change that for 0.8.x.x
    I’ll also double check that there is a “fixed” field as one of the items in the POST payload sent for buildFinished events.

    Thanks for your feedback, and I’m glad tcWebHooks is useful for you.

    Lloyd Holman said:
    March 31, 2011 at 08:00

    Hi,

    What a great plugin, I approached the guys over at http://www.hipchat.com to discuss TeamCity integration and they suggested using tcWebHooks.
    We have everything configured and working but I’m only ever seeing a status of “Running”, for both the buildStarted and buildFinished hooks.
    I have posted the generated messages here http://www.postbin.org/1bh507g if it helps you to diagnose. The guys at HipChat said they will make a public release of TeamCity integration once this is fixed.

    Thanks again for a well thought out and implemented plugin.

    netwolfuk responded:
    March 31, 2011 at 10:46

    Hi Lloyd. Thanks for your feedback.

    The “buildStatus” is the status as presented by TeamCity itself. The code in the payload implementation looks like this…

    paramList.put(“buildStatus”, sRunningBuild.getStatusDescriptor().getText());

    The sRunningBuild is the instance of the build that TeamCity passes to the notifier, so I have just put it directly in. However, as you’ve pointed out, this is not overly helpful. From memory, there are some cases where it’s not “running”, but that certainly seems to be the default for most notifications.

    There is the “notifyType” field which is the name of the event that triggered the hook and is addd by the webhook’s payload implementation (my code). This corresponds to the events you’ve chosen to be notified about in the Webhooks UI. Perhaps that would be more useful?

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