We are occasionally getting a “Null” message when using tcwebhooks to send info to hipchat with the latest alpha version after upgrading to TeamCity 7.1. Any chance this could be fixed?
Using the newest Alpha with TeamCity 7.1 and HipChat but never get any posts into the room. Do you use the room id or the room name? I ask as I have to use room name with my Codebase posts to HipChat?
Love to try and pick your brains over this sometime…
Hi Paul. I chatted to Jay via email and he confirmed that it is changes to responsibility that are sending null messages. The others should still work. I think that the ResponsibilityChanged extention point has changed in 7.1 and I am not overriding the new method. I am working on a fix to tcWebhooks that does not change the payload interface, but it’s looking like I’ll have to change it and then update all the payloads (and break any that anyone else has developed for their own use).
There sure is. Have a look at http://requestb.in/
I use it for testing when I code the plugin.
You need to create a bin on requestbin and then point a new webhook at it.
You can then see all the detail that tcWebHooks sends.
The logic for HipChat looks like this….
if ( buildStatusHtml != null && buildStatusHtml != “” ) {
post buildStatusHtml to channel
} else {
post message to channel
}
It does that check so that users with old versions of tcWebHooks which don’t send the the html message would still get the plain text one in their channel.
Does the web hook plugin respect TeamCity Configuration Parameters, System Properties or Environment Variables? Purpose being being I want to create a single web hook to integrate to slack which I would create at the root of teamcity however I want one build to go to one channel in slack and another to go to another channel. I would therefore provide different tokens by the means of wither a parameter, property or variable.
That was always the intention. However I can’t remember if I ever implemented it. Which would you prefer from the three? If any have been implemented it would be build properties.
bronumski said:
September 19, 2014 at 14:56
Any of the three would work for us, we can give it a go. I’ll let you know how we get on.
If I implemented it, build properties should be copied into the extra parameters map. This is the map of parameters you manually configure in my slack example blog post. In theory you could just copy those parameters from that post and create them as build properties instead. I’m really hoping I implemented it now. 🙂
Feature Request: checkbox for “Build Failed”. I need to send message to HipChat repeatedly if build fails, not only if it changes from Success -> Failed the first time. Thank you for all the hard work on the existing features. Was very simple to install and use out of the box.
The Success -> Failed option is the event in the notification API that is triggered during a build when the first failure occurs. So for example, the first test fails, or the code does not compile. It’s basically the earliest point in a build that TeamCity knows the build will not be successful.
This event happens at most once per build, and could happen on every build if the build continues to fail.
I suspect this is actually what you want, but it is poorly labelled in the UI. In version 0.8, I am removing this because it is so misleading, and replacing it with logic to manufacture success or failure, and broken or fixed events which would fire on build completed.
Reading between the lines, you appear to want to just trigger on failure, but also every time a build fails (not just the first failure). Arguably, you could do this by looking at the result of a CompletedBuild notification, and forwarding that to HipChat if the result is failed. However, I’ve noticed from comments on the blog that most people tend to use third party end points rather than write their own. Therefore, they don’t have a chance to intervene.
I’m hoping to get version 0.8 done soon. Perhaps in the next week. I’d be interested in some alpha testers, so please get in touch if you would like to help.
Thanks for this webhooks library. We’re using it to integrate into HipChat also. One major thing missing is actual links to the build/log page upon failure. It would be nice to not have to go to the build manually and instead just click right through.
Hi Mike. An alpha release of tcWebhooks is now available, with two extra fields for your hipchat integration. buildStatusUrl, which is a link back to your build instance, and buildStatusHtml which is an HTML message with links back to the project, buildType and build instance. See; https://netwolfuk.wordpress.com/2012/05/18/tcwebhooks-alpha-release-available-now-much-better/
I don’t see output in the TC build log that the webhook has fired. Should it be in the general log or should I be looking somewhere else? I’m a bit of a n00b so I may be missing something obvious. I’m trying to send a disable notification command to Nagios. Thanks in advance.
HI Mack. I don’t think the webhooks will appear in the build log, but they should appear in the teamcity-server.log on the TeamCity Server. grep -i for webhook and you should see it firing the events.
If you enable debug logging, you should see a bit more logging appear in the teamcity-server.log file.
Sorry for not being specific enough. I have added a new field rather than change the existing one (path of least surprise for non-hipchat users). I guess hipchat might have to do something at their end to look for the new field. I’ll email them.
It would be nice if you could have tcwebhook not fire if the failure was because of a snapshot failure. When you have long build chains this causes several failure messages when really you want the first one that cause the real failure.
Hi Jay. That would mean having to maintain state across a bunch of indpendent builds. I don’t think teamcity provides an easy way to hook into that. If you setup email notifications using TeamCity’s default emailer does it do what you want? Or do you get multiple email messages there too? If that does exhibit the correct behaiviour, I could ask them how to do it.
Hey, we’re using your plugin to provide webhooks integration for Pivotal ProjectMonitor (https://github.com/pivotal/projectmonitor), a big visible chart aggregator for CI servers including TeamCity. Thanks for the great work. We’d find it quite useful if the payload included a build URL to the TeamCity instance. We can get the REMOTE_ADDR from the request header but it’s only an IP address with no path to the build itself.
TeamCity 7.1 introduced support for automatically building feature branches for Git and Mercurial. Would it be possible to have the name of the branch being built added to the data posted?
I’ve installed webhooks plugin 0.8 to our TC 7.0.3 – works great! Thanks a lot.
One thing that I miss so much is impossibility to configure WebHooks for individual builds – not projects. So, the problem is: I’ve got a project and I would like to be notified if some builds are started/failed and other builds – failed only. Currently I can only configure general rules for all builds in project.
Hi netwolf,
First of all, thanks for a great plugin. And now, a feature request:
We are using an integrated CI/CD system which communicates with TeamCity mainly via the REST API. Would it be possible to have the plugin also extend the API in such a way that we could set/edit webhooks through REST API?
Ory
I think your request would be better suited as a teamcity feature request considering the rest api plugin is bundle with teamcity. You can file one here:
@Ory, @Jay.
I had a look at the REST API over the weekend and from what I can tell the only way Jetbrains would implement tcWebHooks support it would be to expose editing of the project-settings.xml directly. I suspect this is unlikely to happen, so it’s up to plugin developers to implement a higher level REST API if they want to.
I guess that’s a long way of saying, if you want it it’s up to me (or us) to write it.
There is at least an example plugin here: http://svn.jetbrains.org/teamcity/plugins/rest-api/trunk/src/jetbrains/buildServer/server/restcontrib/
We just updated to TeamCity 8 and it looks like the tcWebHooks plugin has stopped working. We’re not getting any notifications on the receiving end, and we’ve tried sending to RequestBin and still didn’t see anything getting sent. Any chance you could confirm TC 8 support when you have time?
Hmm. That’s odd. For me the webhooks still work fine, but I couldn’t edit them. I have released a new version that allows editing of webhooks on TC8. Can you try that?
[…] TeamCity REST API looks to be quite popular (I’ve not knowingly used it). I’ve had a request to add REST API support to tcWebHooks. I’ve not written a public webservices API before. Only […]
I was thinking about that today. It’s probably worth doing that before the REST API so that it’s supported from the start. I’m hoping to start looking at it this week.
I’m not professional Java programmer, but recently I made TC plugin for avatar displaying – https://github.com/grundic/teamcity-avatar.
I used JAXB instead JDOM, imho, it’s easier to implement and support. Maybe you’ll want to refactor your plugin using this tecnology.
Yeah, that’s much tidier than what I was doing. I’ll put that on the list of things to do. 😉
Thanks for the tip!
Chris said:
July 2, 2013 at 14:10
Hi, tcWebHooks is great – I’ve used it before with my Nabaztag, and am now trying it with an Electric Imp.
But I’m having problems running 0.8.29.142 with TeamCity 7.1.1. The installation and restart seemed to go just fine but clicking on the WebHooks tabs of Project and Configuration gives me an unexpected error and a stack trace.
Great. Thanks for letting me know. I’ve written a small wrapper around the parts of the new API that I care about so hopefully won’t see this limitation in future versions of the plugin. * usual disclaimer applies
[…] It supports TC8 and TC7 (and probably earlier versions) and is ready for anybody who wants to use it. Please post any feedback below or on the bugs page. […]
Thanks a million for this plugin, loving using it as integration with Webhook. One feature request / bug though – if we have a build chain set up, and one step in the build chain fails, then we get a notification for every subsequent step in the build chain. (imagine build -> integration tests -> deploy to test -> feature tests -> deploy to staging). If build fails, then we get a notification for all the others failing too. Is there a way we can stop this?
Hi James. Thanks for your comments. I’m not sure of a way to get that from the TeamCity api. I’ve started a forum topic on it and hopefully a TeamCity support person can point me in the right direction.
I am using text from buildStatus field on build finished trigger.
Also I append build status by using teamcity-info.xml file.
For example, this is portion of Teamcity buildlog:
[12:59:50]Build status is taken from teamcity-info.xml: FAILURE
[12:59:50]Total: 7 (+0 -0) Errors: 0 (+0 -0)
[12:59:50]Status text is taken from teamcity-info.xml: Process exited with code 1; problem reported from teamcity-info.xml; inspections total: 7, errors: 0; coffeeLint failed!
[12:59:50]Build finished
This is correct status text.
But in tcWebHooks buildStatus field appears only “Process exited with code 1; problem reported from teamcity-info.xml”
The result displayed by tcwebhooks is just whatever TeamCity returns from the status methods of sBuild in the api. I don’t do any manipulation on that. I’ll have a look and see if there are avenue new methods that might provide more information.
We are loving tcWebHooks integration to our HipChat room, one small issue is that our TeamCity build configurations handle multiple branch configurations and the messages posted don’t include the branch name. Could this be added? Also could the name of the committer be used instead of trigger?
E.g.
ProjectA :: MyProject # 0.0.16.71 has finished with a status of failure and was triggered by Git
.. to ..
ProjectA :: MyProject # 0.0.16.71 [myBranch] has finished with a status of failure and was triggered by Ian Battersby
Any fix to the subproject bug? When setting a webhook at the parent level of a project that has subprojects the webhooks don’t fire for them. To get this working you have to configure the webhook at the build configuration level.
Update, this works if you set it at the subproject level not at the project level that contains the subprojects. I have a workaround but still something wrong that the top level project webhooks aren’t used downstream in subprojects.
Hi Jay. Sorry for the delay. I’ve finally got a new computer now after the burglary but also have a new baby. I’m hoping to get a chance to look at this soon but have no ETA and no progress yet.
Wow, thanks for the quick turn around! I did a quick test and all is working with my integration to flowdock, I’m going to customize the messages now for full effect. Thanks again!
It seems like all the custom webhook stuff has disappeared, the wiki link doesn’t take you where it should, I don’t see anything about it in the UI, I assume there’s some config somewhere but I don’t know where it is or how to add something to it.
Yes. It appears that the trac instance was removed by sourceforge so all the docs have gone. 😦 I’ll have to rewrite it all. I’m in the process of moving to github so will write and check it in as part of the project. Frustrating. I must’ve missed an email from sourceforge at some point.
Thanks, though I have no idea where to edit my project’s xml. Is it in mysql if I’m using that? Or is there a settings file in .BuildServer/config I’m not seeing?
Oh yeah. Sorry. It will be in .BuildServer/config/project name/projects-settings/project.xml or something like that. Sorry, I can’t remember the exact name as it changed in version 8 of TeamCity.
Maxim said:
August 22, 2014 at 06:55
Hello
Can I send build status for many people through sevabot.
I tried to write params like this
Hello, sorry for duplicate comment, but I forgot to subscribe for new comments.
Can I send build status for many people through sevabot.
I tried to write params like this
Hi Net Wolf, thanks for the reply! I did not run this version before the upgrade , we were using TeamCity 7 and an older version of tcWebHooks (0.7.x). I did not start the new version of TeamCity with the old version of WebHooks… I cleaned it out before I launched the new version.
I found an exception in the TomCat (6.x) log, this is the relevant line:
[2014-09-12 14:49:40,735] ERROR – jetbrains.buildServer.SERVER – Error javax.servlet.ServletException: org.apache.jasper.JasperException: /plugins/tcWebHooks/WebHook/projectWebHookTab.jsp(14,4) The function isEnabled must be used with a prefix when a default namespace is not specified while processing request: GET ‘/TeamCity/viewType.html?buildTypeId=bt356&tab=webHooks’
Unfortunately I’m not a Java/JSP person so this error is a bit gibberish to me.
OK. Thanks for testing that. I’ll try it out 8.1.4 over the weekend and see if I can reproduce it. Are you running TeamCity and tomcat bundled or running the war in your own tomcat? Also what JVM are you using on which is?
FYI. I just tried TeamCity 8.1.4 for Linux as downloaded from jetbrains (which bundles tomcat 7) and it works. So it must be a tomcat 6 problem or rhel. I’ll try tomcat 6 and the TeamCity war version over the weekend.
Michael G said:
September 13, 2014 at 02:14
I cleaned up the work directory to no avail. Unfortunately I don’t have the liberty of running Tomcat 7 on our TeamCity server.
I have managed to reproduce the problem. It was laziness on my behalf accessing objects from a javabean in JSP.
It appears the version of jasper (the JSP engine) running in Tomcat6 is less lenient on sloppy coding 🙂
A new version of the plugin has been published: http://tcplugins.sourceforge.net/files/tcWebHooks
Michael G said:
September 13, 2014 at 15:48
🙂 thanks! If you’re willing email me paypal info or a physical address, I’d like to send you something for your efforts.
Richard Hevesi said:
June 16, 2015 at 12:09
Hi Net Wolf!
We are running on 0.9.27.61, Teamcity 8.1.4. It seems the value of “Only trigger when build changes from Success to Failure” checkbox does not get saved.
1. Click “Trigger when build Fails”
2. Click “Only trigger when build changes from Success to Failure”
3. Click “Save”
4. Edit the same webhook to verify that it did save/try to save.
5. Refresh the page.
6. Edit the same webhook.
7. You should notice that “Only trigger when build changes from Success to Failure” box is not checked.
The webhook is triggered for consecutive failures, so I suspect that it is not a UI bug.
Is it possible for tcwebhooks to report (post) more details than the standard build related information. I’m looking for a way to get couple more information like start time, end time, number of test cases, pass count, fail count etc. These informations are available if we hit the rest url (https://teamcity-server.com/app/rest/builds/id:12345) provided by teamcity for a given build run.
I haven’t looked at the code, but it seems to me that the webhooks are executed sequentially which means that if some machines are not responding then it takes ages for the last endpoint to be reached. Whould it be possible to fire all webhooks at once in parallel?
Hi, I just installed tcWebHooks plugin 1.1.318.391 and REST API on TeamCity 2019.1.65998. When I click on “Click to create new WebHook for this project” nothing happens. I’ve tried Chrome, Firefox, and IE. Any suggestions? Thanks!
June 16, 2011 at 12:37
[…] As usual, get the latest from sourceforge. If you find a bug please leave a comment below, or on the bugs page. […]
August 31, 2012 at 19:26
Hi,
We are occasionally getting a “Null” message when using tcwebhooks to send info to hipchat with the latest alpha version after upgrading to TeamCity 7.1. Any chance this could be fixed?
Thanks,
Jay
September 21, 2012 at 21:41
Hey Jay
Using the newest Alpha with TeamCity 7.1 and HipChat but never get any posts into the room. Do you use the room id or the room name? I ask as I have to use room name with my Codebase posts to HipChat?
Love to try and pick your brains over this sometime…
Thanks Paul
September 22, 2012 at 01:12
Hi Paul. I chatted to Jay via email and he confirmed that it is changes to responsibility that are sending null messages. The others should still work. I think that the ResponsibilityChanged extention point has changed in 7.1 and I am not overriding the new method. I am working on a fix to tcWebhooks that does not change the payload interface, but it’s looking like I’ll have to change it and then update all the payloads (and break any that anyone else has developed for their own use).
According to the HipChat docs (http://help.hipchat.com/knowledgebase/articles/64452-teamcity-integration) either room name or room id should work. Unfortunately I don’t use HipChat, so can’t confirm.
I’ve found HipChat support (Gareth) to be very responsive. Maybe email them too.
September 22, 2012 at 07:51
hey thanks netwolfuk. is there any way to test/ debug what exactly TeamCity is sending out then I can check this with HipChat?
September 22, 2012 at 08:19
There sure is. Have a look at http://requestb.in/
I use it for testing when I code the plugin.
You need to create a bin on requestbin and then point a new webhook at it.
You can then see all the detail that tcWebHooks sends.
The logic for HipChat looks like this….
if ( buildStatusHtml != null && buildStatusHtml != “” ) {
post buildStatusHtml to channel
} else {
post message to channel
}
It does that check so that users with old versions of tcWebHooks which don’t send the the html message would still get the plain text one in their channel.
September 19, 2014 at 13:05
Does the web hook plugin respect TeamCity Configuration Parameters, System Properties or Environment Variables? Purpose being being I want to create a single web hook to integrate to slack which I would create at the root of teamcity however I want one build to go to one channel in slack and another to go to another channel. I would therefore provide different tokens by the means of wither a parameter, property or variable.
September 19, 2014 at 14:37
That was always the intention. However I can’t remember if I ever implemented it. Which would you prefer from the three? If any have been implemented it would be build properties.
September 19, 2014 at 14:56
Any of the three would work for us, we can give it a go. I’ll let you know how we get on.
Thank,
September 19, 2014 at 15:02
If I implemented it, build properties should be copied into the extra parameters map. This is the map of parameters you manually configure in my slack example blog post. In theory you could just copy those parameters from that post and create them as build properties instead. I’m really hoping I implemented it now. 🙂
September 22, 2014 at 11:36
This has now been implemented.
You can use any of the three in your custom parameter declaration.
September 20, 2011 at 14:13
Feature Request: checkbox for “Build Failed”. I need to send message to HipChat repeatedly if build fails, not only if it changes from Success -> Failed the first time. Thank you for all the hard work on the existing features. Was very simple to install and use out of the box.
September 22, 2011 at 09:16
Hi Jason. Thanks for your feature request.
The Success -> Failed option is the event in the notification API that is triggered during a build when the first failure occurs. So for example, the first test fails, or the code does not compile. It’s basically the earliest point in a build that TeamCity knows the build will not be successful.
This event happens at most once per build, and could happen on every build if the build continues to fail.
I suspect this is actually what you want, but it is poorly labelled in the UI. In version 0.8, I am removing this because it is so misleading, and replacing it with logic to manufacture success or failure, and broken or fixed events which would fire on build completed.
Reading between the lines, you appear to want to just trigger on failure, but also every time a build fails (not just the first failure). Arguably, you could do this by looking at the result of a CompletedBuild notification, and forwarding that to HipChat if the result is failed. However, I’ve noticed from comments on the blog that most people tend to use third party end points rather than write their own. Therefore, they don’t have a chance to intervene.
I’m hoping to get version 0.8 done soon. Perhaps in the next week. I’d be interested in some alpha testers, so please get in touch if you would like to help.
September 22, 2011 at 15:00
I would love to help test out the new version. Please let me know. Thank you for the hard work.
May 18, 2012 at 10:44
Hi Jason. It’s finally ready for alpha testing. Please see this post: https://netwolfuk.wordpress.com/2012/05/18/tcwebhooks-alpha-release-available-now-much-better/
October 12, 2011 at 19:01
Thanks for this webhooks library. We’re using it to integrate into HipChat also. One major thing missing is actual links to the build/log page upon failure. It would be nice to not have to go to the build manually and instead just click right through.
May 18, 2012 at 10:42
Hi Mike. An alpha release of tcWebhooks is now available, with two extra fields for your hipchat integration. buildStatusUrl, which is a link back to your build instance, and buildStatusHtml which is an HTML message with links back to the project, buildType and build instance. See; https://netwolfuk.wordpress.com/2012/05/18/tcwebhooks-alpha-release-available-now-much-better/
October 31, 2011 at 22:51
I don’t see output in the TC build log that the webhook has fired. Should it be in the general log or should I be looking somewhere else? I’m a bit of a n00b so I may be missing something obvious. I’m trying to send a disable notification command to Nagios. Thanks in advance.
November 1, 2011 at 04:54
HI Mack. I don’t think the webhooks will appear in the build log, but they should appear in the teamcity-server.log on the TeamCity Server. grep -i for webhook and you should see it firing the events.
If you enable debug logging, you should see a bit more logging appear in the teamcity-server.log file.
May 18, 2012 at 04:25
[…] As usual, please put comments below or on the bugs page. […]
May 18, 2012 at 14:38
Just had a build fail after installing the Alpha release. No link back to build and the status was an empty string:
Build #1531 of “Project X :: master” finished with status “”. Triggered by “githook”.
May 18, 2012 at 14:38
That is in a HipChat chat room
May 18, 2012 at 20:51
Sorry for not being specific enough. I have added a new field rather than change the existing one (path of least surprise for non-hipchat users). I guess hipchat might have to do something at their end to look for the new field. I’ll email them.
May 18, 2012 at 21:10
oh. The status was empty. That’s not cool. I’ll look into that. Thanks for your feedback
May 20, 2012 at 00:23
New alpha release available. It should fix the empty string problem.
https://netwolfuk.wordpress.com/2012/05/20/tcwebhooks-0-8-alpha-bugfix-release/
May 20, 2012 at 00:19
[…] pretty sure Jason’s comment regading the hipchat message field containing a blank build result was caused by the buildResult […]
August 9, 2012 at 19:43
It would be nice if you could have tcwebhook not fire if the failure was because of a snapshot failure. When you have long build chains this causes several failure messages when really you want the first one that cause the real failure.
August 23, 2012 at 09:52
Hi Jay. That would mean having to maintain state across a bunch of indpendent builds. I don’t think teamcity provides an easy way to hook into that. If you setup email notifications using TeamCity’s default emailer does it do what you want? Or do you get multiple email messages there too? If that does exhibit the correct behaiviour, I could ask them how to do it.
August 22, 2012 at 15:10
Hey, we’re using your plugin to provide webhooks integration for Pivotal ProjectMonitor (https://github.com/pivotal/projectmonitor), a big visible chart aggregator for CI servers including TeamCity. Thanks for the great work. We’d find it quite useful if the payload included a build URL to the TeamCity instance. We can get the REMOTE_ADDR from the request header but it’s only an IP address with no path to the build itself.
August 23, 2012 at 09:48
Hi Andrew. The latest Alpha includes the URL of the teamcity server and also a field containing a link back to the specific build.
Thanks for reminding me I should really tidy it up and post a proper release.
September 24, 2012 at 21:16
Hi netwolf,
I use the room_id. Send me an email directly if you want to chat.
Thanks,
Jay
November 21, 2012 at 15:55
TeamCity 7.1 introduced support for automatically building feature branches for Git and Mercurial. Would it be possible to have the name of the branch being built added to the data posted?
Thanks!
November 26, 2012 at 09:41
Hi Justin.
It looks like TC 7.1 added a “Branch” interface to the OpenAPI. I will look at adding that to the payload delivered by tcWebHooks.
Thanks for pointing it out.
November 27, 2012 at 17:56
Awesome, looking forward to it. Thanks!
January 9, 2013 at 05:36
Hello!
I’ve installed webhooks plugin 0.8 to our TC 7.0.3 – works great! Thanks a lot.
One thing that I miss so much is impossibility to configure WebHooks for individual builds – not projects. So, the problem is: I’ve got a project and I would like to be notified if some builds are started/failed and other builds – failed only. Currently I can only configure general rules for all builds in project.
Is it possible to implement?
Thanks in advance.
June 17, 2013 at 12:59
Hi netwolf,
First of all, thanks for a great plugin. And now, a feature request:
We are using an integrated CI/CD system which communicates with TeamCity mainly via the REST API. Would it be possible to have the plugin also extend the API in such a way that we could set/edit webhooks through REST API?
Ory
June 17, 2013 at 13:27
@Ory,
I think your request would be better suited as a teamcity feature request considering the rest api plugin is bundle with teamcity. You can file one here:
http://youtrack.jetbrains.com/dashboard/TW#tab=0
June 23, 2013 at 11:52
@Ory, @Jay.
I had a look at the REST API over the weekend and from what I can tell the only way Jetbrains would implement tcWebHooks support it would be to expose editing of the project-settings.xml directly. I suspect this is unlikely to happen, so it’s up to plugin developers to implement a higher level REST API if they want to.
I guess that’s a long way of saying, if you want it it’s up to me (or us) to write it.
There is at least an example plugin here:
http://svn.jetbrains.org/teamcity/plugins/rest-api/trunk/src/jetbrains/buildServer/server/restcontrib/
I’ll put my thoughts into a blog post.
June 21, 2013 at 18:20
We just updated to TeamCity 8 and it looks like the tcWebHooks plugin has stopped working. We’re not getting any notifications on the receiving end, and we’ve tried sending to RequestBin and still didn’t see anything getting sent. Any chance you could confirm TC 8 support when you have time?
Thanks for the plugin!
June 21, 2013 at 20:48
Thanks for your comment. Is there anything useful in the TeamCity server log?
June 22, 2013 at 12:40
Unfortunately no; nothing at all regarding the webhook firing/not-firing.
June 22, 2013 at 12:48
Hmm. That’s odd. For me the webhooks still work fine, but I couldn’t edit them. I have released a new version that allows editing of webhooks on TC8. Can you try that?
June 22, 2013 at 12:55
Also. What version of the plugin were you using?
June 22, 2013 at 12:45
[…] my test server running TC8. If you find anything different, please post a comment below or on the Bugs […]
June 22, 2013 at 13:40
Just tried the new version and we’re back in business. Thanks!
June 22, 2013 at 21:15
That’s great. Thanks for the feedback.
June 23, 2013 at 12:15
[…] TeamCity REST API looks to be quite popular (I’ve not knowingly used it). I’ve had a request to add REST API support to tcWebHooks. I’ve not written a public webservices API before. Only […]
June 24, 2013 at 05:38
@netwolfuk,
is it possible to implement per build configuration? Take a look at my comment above.
June 24, 2013 at 05:46
I was thinking about that today. It’s probably worth doing that before the REST API so that it’s supported from the start. I’m hoping to start looking at it this week.
June 24, 2013 at 08:35
@netwolfuk
good news!
Any plans to move on git?
I’m not professional Java programmer, but recently I made TC plugin for avatar displaying – https://github.com/grundic/teamcity-avatar.
I used JAXB instead JDOM, imho, it’s easier to implement and support. Maybe you’ll want to refactor your plugin using this tecnology.
https://github.com/grundic/teamcity-avatar/tree/master/server/src/ru/mail/teamcity/avatar/config
June 24, 2013 at 08:48
Yeah, that’s much tidier than what I was doing. I’ll put that on the list of things to do. 😉
Thanks for the tip!
July 2, 2013 at 14:10
Hi, tcWebHooks is great – I’ve used it before with my Nabaztag, and am now trying it with an Electric Imp.
But I’m having problems running 0.8.29.142 with TeamCity 7.1.1. The installation and restart seemed to go just fine but clicking on the WebHooks tabs of Project and Configuration gives me an unexpected error and a stack trace.
Any suggestions about how I resolve this?
July 2, 2013 at 19:25
Hi Chris. 0.8.29.142 was a release against the new TeamCity 8.0 API and won’t work on TC7. Please try 0.8.27.139 from here http://tcplugins.sourceforge.net/files/tcWebHooks
More details: https://netwolfuk.wordpress.com/2013/06/22/tcwebhooks-release-to-support-teamcity-8/
July 2, 2013 at 20:00
5 stars for sterling support! A simple re-install with the right version and I’m up and running in less than five minutes.
July 2, 2013 at 20:50
Great. Thanks for letting me know. I’ve written a small wrapper around the parts of the new API that I care about so hopefully won’t see this limitation in future versions of the plugin. * usual disclaimer applies
July 7, 2013 at 10:41
[…] alpha – Download and feedback […]
July 11, 2013 at 12:42
[…] Please try it out and let me know if you find any more bugs. […]
July 21, 2013 at 01:41
[…] It supports TC8 and TC7 (and probably earlier versions) and is ready for anybody who wants to use it. Please post any feedback below or on the bugs page. […]
October 10, 2013 at 12:43
Thanks a million for this plugin, loving using it as integration with Webhook. One feature request / bug though – if we have a build chain set up, and one step in the build chain fails, then we get a notification for every subsequent step in the build chain. (imagine build -> integration tests -> deploy to test -> feature tests -> deploy to staging). If build fails, then we get a notification for all the others failing too. Is there a way we can stop this?
Thanks!
October 11, 2013 at 08:04
Hi James. Thanks for your comments. I’m not sure of a way to get that from the TeamCity api. I’ve started a forum topic on it and hopefully a TeamCity support person can point me in the right direction.
October 18, 2013 at 10:50
Great, thanks! 🙂
October 21, 2013 at 10:44
Hello, I have problem with tcWebHooks plugin.
I am using text from buildStatus field on build finished trigger.
Also I append build status by using teamcity-info.xml file.
For example, this is portion of Teamcity buildlog:
[12:59:50]Build status is taken from teamcity-info.xml: FAILURE
[12:59:50]Total: 7 (+0 -0) Errors: 0 (+0 -0)
[12:59:50]Status text is taken from teamcity-info.xml: Process exited with code 1; problem reported from teamcity-info.xml; inspections total: 7, errors: 0; coffeeLint failed!
[12:59:50]Build finished
This is correct status text.
But in tcWebHooks buildStatus field appears only “Process exited with code 1; problem reported from teamcity-info.xml”
Is this tcWebHooks plugin problem or Teamcity?
November 8, 2013 at 17:51
The result displayed by tcwebhooks is just whatever TeamCity returns from the status methods of sBuild in the api. I don’t do any manipulation on that. I’ll have a look and see if there are avenue new methods that might provide more information.
November 25, 2013 at 06:58
Is there any way to easily configure how the data is returned under the “json” payload? I’d like to have it all under ‘payload’ instead of ‘build’
November 25, 2013 at 07:05
No. Sorry there isn’t.
January 9, 2014 at 13:02
We are loving tcWebHooks integration to our HipChat room, one small issue is that our TeamCity build configurations handle multiple branch configurations and the messages posted don’t include the branch name. Could this be added? Also could the name of the committer be used instead of trigger?
E.g.
ProjectA :: MyProject # 0.0.16.71 has finished with a status of failure and was triggered by Git
.. to ..
ProjectA :: MyProject # 0.0.16.71 [myBranch] has finished with a status of failure and was triggered by Ian Battersby
Thanks!
January 14, 2014 at 20:27
You can definitely add the branch name. See the info on this page:
http://sourceforge.net/apps/trac/tcplugins/wiki/TcWebHooksCustomTemplates
February 12, 2014 at 15:01
Any fix to the subproject bug? When setting a webhook at the parent level of a project that has subprojects the webhooks don’t fire for them. To get this working you have to configure the webhook at the build configuration level.
February 12, 2014 at 15:08
Update, this works if you set it at the subproject level not at the project level that contains the subprojects. I have a workaround but still something wrong that the top level project webhooks aren’t used downstream in subprojects.
February 27, 2014 at 10:53
New alpha release here Jay. Fixes the subproject bug. http://sourceforge.net/projects/tcplugins/files/tcWebHooks_plugin/tcWebHooks-0.9-alpha-releases%20%280.9.x.x%20branch%29/tcWebHooksPlugin-0.9.14.161.zip/download
February 15, 2014 at 00:41
Hi Jay. Sorry for the delay. I’ve finally got a new computer now after the burglary but also have a new baby. I’m hoping to get a chance to look at this soon but have no ETA and no progress yet.
February 27, 2014 at 10:52
Thanks for your comments Pieter. I have a version that fixes the subproject bug. I’ve released it as alpha, but will promote if no new bugs appear.
http://sourceforge.net/projects/tcplugins/files/tcWebHooks_plugin/tcWebHooks-0.9-alpha-releases%20%280.9.x.x%20branch%29/tcWebHooksPlugin-0.9.14.161.zip/download
February 27, 2014 at 11:24
Thanks!
February 28, 2014 at 10:58
New version: http://sourceforge.net/projects/tcplugins/files/tcWebHooks_plugin/tcWebHooks-0.9-alpha-releases%20%280.9.x.x%20branch%29/tcWebHooksPlugin-0.9.15.162.zip/download
Fixes a bug in the UI where all builds from all subprojects were listed, but without any webhooks (even if there were some configured). It now just shows builds for the current project.
I plan to put in a nicer interface to show webhooks inherited from parent projects. I am just trying to plan the best way to implement it.
March 20, 2014 at 17:41
Wow, thanks for the quick turn around! I did a quick test and all is working with my integration to flowdock, I’m going to customize the messages now for full effect. Thanks again!
April 2, 2014 at 11:16
[…] tcWebHooks Bugs and Feature Requests […]
July 9, 2014 at 08:58
Hi,
Webhook from TC to HipChat works great with name value pairs, is there a way to send other text as message to HipChat room?
Thanks,
Avner
July 16, 2014 at 19:15
Yes. It’s customisable. However the docs have disappeared from sourceforge. I’ll try and dig out an example.
July 16, 2014 at 19:26
You need to add the custom template block into the XML like this example. https://github.com/tcplugins/tcWebHooks/blob/0.9.x.x/tcwebhooks-core/src/test/resources/project-settings-test-all-states-enabled-with-custom-templates.xml
July 16, 2014 at 18:24
It seems like all the custom webhook stuff has disappeared, the wiki link doesn’t take you where it should, I don’t see anything about it in the UI, I assume there’s some config somewhere but I don’t know where it is or how to add something to it.
July 16, 2014 at 19:11
Yes. It appears that the trac instance was removed by sourceforge so all the docs have gone. 😦 I’ll have to rewrite it all. I’m in the process of moving to github so will write and check it in as part of the project. Frustrating. I must’ve missed an email from sourceforge at some point.
July 16, 2014 at 19:57
How do I do custom templates? I can’t find any of the docs linked to…
July 16, 2014 at 20:03
Until I get to rewrite the docs you can look at this as a very simple example. https://github.com/tcplugins/tcWebHooks/blob/0.9.x.x/tcwebhooks-core/src/test/resources/project-settings-test-all-states-enabled-with-custom-templates.xml
The list of variables available is at the bottom of this post: https://netwolfuk.wordpress.com/2013/08/31/custom-templates-and-branches-in-tcwebhooks/
July 16, 2014 at 20:07
Thanks, though I have no idea where to edit my project’s xml. Is it in mysql if I’m using that? Or is there a settings file in .BuildServer/config I’m not seeing?
July 16, 2014 at 20:11
Oh yeah. Sorry. It will be in .BuildServer/config/project name/projects-settings/project.xml or something like that. Sorry, I can’t remember the exact name as it changed in version 8 of TeamCity.
August 22, 2014 at 06:55
Hello
Can I send build status for many people through sevabot.
I tried to write params like this
but only one person has got message
August 22, 2014 at 06:57
Hello, sorry for duplicate comment, but I forgot to subscribe for new comments.
Can I send build status for many people through sevabot.
I tried to write params like this
but only one person has got message
August 24, 2014 at 12:34
Hello. I created group chat and added all needed people + my bot there.
August 25, 2014 at 03:30
I tryed to do that, but sevabot does not see chat groups in skype
August 25, 2014 at 18:37
How can it be? You have just add your bot account to group chat and that’s all.
Can’t understand, how it can’t see group chat.
August 26, 2014 at 03:23
It is not only my problem, this problem related with new Skype version, I found an issue at github https://github.com/opensourcehacker/sevabot/issues/78. Thanks for your help.
August 26, 2014 at 04:03
Oh, that’s not good.. I think we should replace skype with something more opened sourced 🙂
September 3, 2014 at 08:58
Hello! I found solution for this situation. Here is it, I downloaded old skype version by magnet link from this post http://community.skype.com/t5/Skype-%D0%B4%D0%BB%D1%8F-Windows/%D0%BD%D0%B5-%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%B0%D0%B5%D1%82-%D1%81%D1%82%D0%B0%D1%80%D0%B0%D1%8F-%D0%B2%D0%B5%D1%80%D1%81%D0%B8%D1%8F-Skype/m-p/3588257#M49004 and it works.
September 12, 2014 at 22:15
Hi Net Wolf, thanks for the reply! I did not run this version before the upgrade , we were using TeamCity 7 and an older version of tcWebHooks (0.7.x). I did not start the new version of TeamCity with the old version of WebHooks… I cleaned it out before I launched the new version.
I found an exception in the TomCat (6.x) log, this is the relevant line:
[2014-09-12 14:49:40,735] ERROR – jetbrains.buildServer.SERVER – Error javax.servlet.ServletException: org.apache.jasper.JasperException: /plugins/tcWebHooks/WebHook/projectWebHookTab.jsp(14,4) The function isEnabled must be used with a prefix when a default namespace is not specified while processing request: GET ‘/TeamCity/viewType.html?buildTypeId=bt356&tab=webHooks’
Unfortunately I’m not a Java/JSP person so this error is a bit gibberish to me.
Redeploying ends up with the same results.
September 12, 2014 at 22:40
OK. Thanks for testing that. I’ll try it out 8.1.4 over the weekend and see if I can reproduce it. Are you running TeamCity and tomcat bundled or running the war in your own tomcat? Also what JVM are you using on which is?
Thanks.
September 13, 2014 at 00:32
I’m running the Tomcat supplied by RHEL, version 6.0.24 with a somewhat older JVM that I’ve been meeaning to upgrade (6U31).
September 13, 2014 at 00:36
I wonder if that’s the problem. If 8.1.4 works for me on java 7 and tomcat 7 I’ll try and find an old Java and tomcat 6 to try.
September 13, 2014 at 00:41
I updated it to Java 7 U67 and still no dice.
September 13, 2014 at 00:43
OK. Can you clear Tomcat’s work dir just to make sure there’s no java6 byte code lying around?
September 13, 2014 at 01:32
FYI. I just tried TeamCity 8.1.4 for Linux as downloaded from jetbrains (which bundles tomcat 7) and it works. So it must be a tomcat 6 problem or rhel. I’ll try tomcat 6 and the TeamCity war version over the weekend.
September 13, 2014 at 02:14
I cleaned up the work directory to no avail. Unfortunately I don’t have the liberty of running Tomcat 7 on our TeamCity server.
Same exception appears.
September 13, 2014 at 02:20
OK. If I can reproduce it, I’ll try and code around it.
September 13, 2014 at 12:38
I have managed to reproduce the problem. It was laziness on my behalf accessing objects from a javabean in JSP.
It appears the version of jasper (the JSP engine) running in Tomcat6 is less lenient on sloppy coding 🙂
A new version of the plugin has been published: http://tcplugins.sourceforge.net/files/tcWebHooks
September 13, 2014 at 15:48
🙂 thanks! If you’re willing email me paypal info or a physical address, I’d like to send you something for your efforts.
June 16, 2015 at 12:09
Hi Net Wolf!
We are running on 0.9.27.61, Teamcity 8.1.4. It seems the value of “Only trigger when build changes from Success to Failure” checkbox does not get saved.
1. Click “Trigger when build Fails”
2. Click “Only trigger when build changes from Success to Failure”
3. Click “Save”
4. Edit the same webhook to verify that it did save/try to save.
5. Refresh the page.
6. Edit the same webhook.
7. You should notice that “Only trigger when build changes from Success to Failure” box is not checked.
The webhook is triggered for consecutive failures, so I suspect that it is not a UI bug.
Many thanks,
Richard
June 16, 2015 at 19:58
Thanks for reporting that. I’ll take a look. And add a unit test for it since that option is obviously not well covered.
June 18, 2015 at 11:57
Thanks for the bug report. It was a typo in the javascript, so of course the unit tests were not finding it.
You can download the fixed version here: http://sourceforge.net/projects/tcplugins/files/tcWebHooks_plugin/tcWebHooks-beta-releases/tcWebHooksPlugin-0.9.29.63.zip/download
I’ve not set it as the default download yet. Let me know how it works for you and if there are not any problems, I’ll change the status to make it the default download.
July 29, 2015 at 11:25
[…] tcWebHooks Bugs and Feature Requests […]
April 5, 2016 at 12:08
Is it possible for tcwebhooks to report (post) more details than the standard build related information. I’m looking for a way to get couple more information like start time, end time, number of test cases, pass count, fail count etc. These informations are available if we hit the rest url (https://teamcity-server.com/app/rest/builds/id:12345) provided by teamcity for a given build run.
April 6, 2016 at 12:06
Hi Thomas. Thanks for the feedback. I have created an issue https://github.com/tcplugins/tcWebHooks/issues/31
May 10, 2016 at 10:31
Hi,
what is the license of this project? Soureforge indicates MIT but there is no license file in github.
Thank you
Jens
May 10, 2016 at 11:51
Yeah. MIT.
September 6, 2016 at 15:06
I haven’t looked at the code, but it seems to me that the webhooks are executed sequentially which means that if some machines are not responding then it takes ages for the last endpoint to be reached. Whould it be possible to fire all webhooks at once in parallel?
September 6, 2016 at 19:09
Yes. You are correct. However, I think running them in a separate thread pool could mask failures. See https://github.com/tcplugins/tcWebHooks/issues/40
June 4, 2019 at 20:37
Hi, I just installed tcWebHooks plugin 1.1.318.391 and REST API on TeamCity 2019.1.65998. When I click on “Click to create new WebHook for this project” nothing happens. I’ve tried Chrome, Firefox, and IE. Any suggestions? Thanks!
June 5, 2019 at 01:26
Hmm. Sounds like a JavaScript problem. Are there any errors in your browser’s console?
June 23, 2019 at 05:52
This week I had another similar question. Does your project or buildType name contain non-ascii characters?
June 26, 2019 at 19:37
Have run into this same problem since upgrading to 2019.1:
Adding a new webhook to the second Build Configuration in the project, but the error given is in step 1…
2019.1 definitely borked something. Here’s the console dump
“`7133815647813188329.js?v=1559309089732:16 Uncaught Error: Syntax error, unrecognized expression: 1. Monitor & Build (Prod)
at Function.fa.error (7133815647813188329.js?v=1559309089732:16)
at fa.tokenize (7133815647813188329.js?v=1559309089732:16)
at fa.select (7133815647813188329.js?v=1559309089732:16)
at Function.fa [as find] (7133815647813188329.js?v=1559309089732:16)
at n.fn.init.find (7133815647813188329.js?v=1559309089732:16)
at new n.fn.init (7133815647813188329.js?v=1559309089732:16)
at n (7133815647813188329.js?v=1559309089732:16)
at Object. (2226768761686555817.js?v=1559309089732:21)
at Function.each (7133815647813188329.js?v=1559309089732:16)
at Object. (2226768761686555817.js?v=1559309089732:21)
fa.error @ 7133815647813188329.js?v=1559309089732:16
fa.tokenize @ 7133815647813188329.js?v=1559309089732:16
fa.select @ 7133815647813188329.js?v=1559309089732:16
fa @ 7133815647813188329.js?v=1559309089732:16
find @ 7133815647813188329.js?v=1559309089732:16
n.fn.init @ 7133815647813188329.js?v=1559309089732:16
n @ 7133815647813188329.js?v=1559309089732:16
(anonymous) @ 2226768761686555817.js?v=1559309089732:21
each @ 7133815647813188329.js?v=1559309089732:16
(anonymous) @ 2226768761686555817.js?v=1559309089732:21
each @ 7133815647813188329.js?v=1559309089732:16
populateWebHookDialog @ 2226768761686555817.js?v=1559309089732:21
showDialog @ 2226768761686555817.js?v=1559309089732:20
showAddDialog @ 2226768761686555817.js?v=1559309089732:20
onclick @ index.html?buildTypeId=Company_Product_3ProductionEnvironment_ProductProd2Deploy:1479
“`
June 26, 2019 at 19:45
Can you confirm the buildType id contains a colon character? I don’t think I’ve tested that.
June 30, 2019 at 11:01
Thanks Ed. A new release is available to address this issue. Thanks for posting your bug report.
https://github.com/tcplugins/tcWebHooks/releases
June 30, 2019 at 11:00
Hi @erikpashanet. A new release is available to address this issue. Thanks for posting your bug report.
https://github.com/tcplugins/tcWebHooks/releases