A new version (0.7.25.115) of the tcWebHooks plugin is available.
With the recent release of Teamcity 6.5, some assumptions I was making about the prototype javascript functions proved incorrect. I think the newer version is stricter with badly named functions, or perhaps teamcity has changed some of their internal functions on which I was mistakenly relying.
This release fixes those bugs and also fixes a long standing oversight in the lack of checking of the URL and payload formats when submitting the form. Now, when trying to add a webhook with no url or no payload format selected you are prompted before the dialog goes away. Previously, the dialog would just close and no webhook would be added. It ended up being that my jsp was not setting the content type to text/xml, so the javascript error listener was never firing.
As usual, get the latest from sourceforge. If you find a bug please leave a comment below, or on the bugs page.
Very nice work!
I use this plug-in to call a service, temporarily enabling/disabling push during build. But I noticed that the event for BuildStarted and BuildCompleted are triggered for each build configuration in a project, but what I would like are events for when the complete project starts a build and is finished building all it’s build configurations. Is there a solution to this, or any new events that you can add to solve this problem?
Best regards,
Joel
Hi Joel. thanks for your feedback.
If I understand your comment correctly, you have a set of builds in your project that have dependencies on each other, and you want to know when the dependency chain starts and finishes?
I’ve had a quick look at the API docs for teamcity and I can’t see how it would be possible to add that based on the events available.
I suspect you’d have to add some logic to your webhook endpoint to figure out where in the chain it is. Perhaps by looking at the trigger reason. It’d be difficult though, as you could enter the chain at any point. It might not always be the first build that triggered the chain.
Or are you referring to a single build with multiple build steps?
If so, I thought that build steps were considered part of a single build. Admittedly I’ve not done much testing with build steps.
Very nice indeed! I’m using it to feed our build bunny.
Our Nabaztag had been quiet ever since Mindscape went bust. But a new Ruby server has been written which listens for tcWebHooks and breathes new life into the every developers favourite rabbit.
https://github.com/quimarche/trudy
That’s very cool. Thanks for the feedback Chris.
Hi,
This is a handy plugin. Does TeamCity provide the flexibility to allow for webhooks per Build Configuration in addition to Project level? I know the plugin doesn’t currently support that but Build-Config level webhooks could be very valuable and also solve Joel’s problem above.
Thanks
Thanks for your comment Frank.
Yes, it’s certainly possible. To be honest, the main reason I’ve not done it is because I’ve not come up with a way of implementing it without making the ui cluttered.
Any suggestions?
I think there are a couple ways to do this. One would be to change the “webhooks” tab on a build to edit hooks for that build, optionally showing the project webhooks as well, like this: http://i.imgur.com/bcVhN.png
(Aside, I don’t think it’s a good UX now that there is a tab on the build level that actually edits the project-level stuff … this would fix that)
Another variation of this is to display a single table, and indicate if the build is per-project or per-build. This COULD be extended to the project level to show all per-build hooks below, but that is obviously a bit harder to implement. I definitely don’t think you need to be able to add per-build hooks while working at the project level – the UI to do that would be even more complex, and really it’s not that hard to pick the build, then the Webhooks tab, and add from there.
Hi Groogs. Thanks for your idea about splitting the config out onto the builds pages. I never really thought about that, but I think it’s becuase I have constrained my thinking to project centric config.
I always assumed that a webhook would apply to more than one build, and that having many seperate ones would be cumbersome if one ever wanted to update the URL for all of them.
For this reason, I was always thinking I’d need to provide a way to select builds if one chose not to make the webhook apply to all in a project.
I think both would be good. When you setup a webhook, you choose which builds it runs on, and then on the builds page, the webhooks plugin shows webhooks that apply to this build as well as ones that don’t.
I’d like to think I could work on this soon, but I am so busy at the moment, I don’t want to make any promises.
Any plans for switching to the new zip-based package format?
Also I was really looking forward to using tcWebHooks in our new TC7 install, but it just crashes, any TC7 supported builds?
The other projects use the zip format. I haven’t done that yet for tcWebhooks.
TC 7 is still in EAP, so I’ve not looked at that yet. Thanks for the reminder.
Hi Patrik, can you tell me more about your crashes? It worked for me on TC7.
There is a problem where events fire without fully populated details, and that is causing a stacktrace to appear in the logs, but that is only for Responsibility changes. The other events should work. I have alerted the TeamCity developers.
Hi Patrik. A new alpha release of tcWebHooks is available. Now with ZIP file deployment. You’re welcome to give it a try: http://netwolfuk.wordpress.com/2012/05/18/tcwebhooks-alpha-release-available-now-much-better/
I’ll make sure to try it out as soon as I get back to the office. Thanks for the update.
Hi,
We’ve been using your tcWebHooks plugin (latest version) for HipChat integration and it’s been great. Thanks for making it.
However, since upgrading to TeamCity 6.5.6 we’ve been getting this exception: https://gist.github.com/1677782
Is tcWebHooks known to work with the latest production TeamCity?
Thanks,
Josh
Hi Josh.
tcWebHooks 0.7.25.115 works for me on TeamCity 6.5.6.
Looking at your error log, it appears that the plugin is installed inside the teamcity webapp WEB-INF/lib folder. Please remove the jar from the lib folder and install the plugin in your .BuildServer/plugins/ folder inside a sub-folder called “tcWebHooks” (or something similar).
The .BuildServer folder will be in your user’s profile folder, unless you are directing Teamcity to locate it somewhere else with a startup flag.
Full docs are at: http://sourceforge.net/apps/trac/tcplugins/wiki/TcWebHooks
Thanks for the help. I missed the subfolder bit. It’s working now. Thanks!
I am using tcWebHooks to integrate with HipChat. I made a request of HipChat to generate a link to the TeamCity build, and heard back that they don’t think they are receiving enough data from TeamCity to generate such a link. Is there an enhancement to tcWebHooks that is necessary for HipChat to enable this, or are they mistaken?
Hi Josh. Yes they are correct. I have it on my list of things todo. Currently tcWebhooks does not send a URL of the teamcity server or the build details, so needs to be enhanced to send that detail.
tcWebhooks is feeling a bit neglicted at the moment while I work on paid gigs.
I can add you to the list of interested parties, and will forward you an alpha version when I get a chance to look at it again. Hopefully in the next month or so.
That would be awesome, thanks!
Hi Josh. Alpha release of tcWebHooks is avilable for testing. See: http://netwolfuk.wordpress.com/2012/05/18/tcwebhooks-alpha-release-available-now-much-better/