The good news is that in version 1.1 of tcWebHooks, it got whole lot easier.
- Install the latest tcWebHooks 1.1 (or higher) plugin into TeamCity.
- Create an incoming webhook in slack.
- Create a webhook in TeamCity and choose from one of the Slack payload formats
- That’s it!
Bundled Slack WebHook Templates
As of the time of writing (December 2017), there are two Slack specific webhook templates bundled with a tcWebHooks release.
1. The “Slack.com JSON templates” payload format has templates which produce a message in slack with some information about the build.
2. The “Slack.com Compact Notification” has templates which produce a more compact notification.
If neither of those are right for you, it’s possible to create your own template by either copying an existing one, or creating a new one.
A WebHook Template is a predefined payload that can be reused with multiple webhook configurations. I’ve prepared a few to get you started, but it’s very easy to modify them or create your own. The ones bundled with tcWebHooks include:
If you’re a tcWebHooks plugin user, could you please take a couple of minutes to post a comment on this poll?
I am trying to determine how much effort I should invest in supporting older versions of TeamCity, and where to focus future development.
There are some new features in TeamCity 10 which I would like to migrate to, and I am wondering how many tcWebHooks users would be affected by discontinuing support for versions 9.x and below.
Also, how tcWebHooks is being used, and what payload formats are popular.
Many thanks in advance for your time.
The 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 really web APIs for services that I control both ends of.
Note: This is not a commitment to build it, more a place to put my thoughts on whether it’s worthwhile or not and how it might work.
I see the four basic requirements.
- Is there anything else needed? Perhaps test?
I think there are three ways it could be accomplished.
- Write it myself and probably get it wrong.
- Write it myself with a lot input from the users. Who is willing to commit to helping me spec it and test it?
- Write a Java API and let someone else write the webservice parts.
The stuff I’ve done before was sending and receiving JSON, and only used POST and GET. Do I need to worry about the whole strict PUT, DELETE etc verbs?
What should the request payload look like? XML? JSON? Name Value Pairs?
What should the response payload look like?
Any good examples? I presume basing it on the existing TeamCity REST API would be the path of least surprise for users. I’ve not used it so don’t have a lot of experience on how it works.