Creating a commit hook based, non-polling situation for entirety of TeamCity. Possible?

Recently, I had to migrate a very large VCS over to bitbucket. After a few months, BitBucket sent me an e-mail saying that our bandwidth on their VCS was rather substantial and we would have to find a way to cut it down. Although I do not have the bandwidth data to see exactly what's causing all the problems, I wouldn't be surprised if TeamCity's version of CI, polling, was the cause. Aside from the fact that "checking for changes" seems to take a significant portion of time for our builds, it seems like the best possible way to do CI would be to enable commit hooks on all of our repositories; which bitbucket lets us do.

Now, in the world of Jenkins, the only thing Jenkins needs to get from a post-commit hook is the repository URL. Jenkins then knows enough about its tasks that it can simply run the task associated with that VCS root. Unfortunately, in the world of TeamCity, VCS roots seem a little more disjointed from their associated tasks ("configurations") and I cannot seem to Google up anything that properly describes how TeamCity can receive a post-commit hook trigger with just the repository URL. It seems like I'd have to pull all build IDs from TeamCity and somehow inject that data on a per-repository host on BitBucket to actually do this.

Does anyone have any experience with this process? Is what I'm asking even possible? Is it as much of a pain as it seems to be? I would hope TeamCity has some way of dealing with this because if it turns out that polling is our primary cause of traffic with BitBucket, we may either have to change our VCS (please no) or stop using TeamCity (please please no.)

3 comments
Comment actions Permalink

One idea I have is to increase to the polling interval. We had a similar problem with SVN and it helped.

It's under Server Admin/Global Settings/Version Control Settings then "Default VCS changes check interval." We have ours set to 300 second (5mins), but for public servers they recommend higher values:

Please note that certain servers can refuse access if polled too frequently. Consider intervals greater than 1800 seconds (30 minutes) for public servers.

Fred

0
Comment actions Permalink

My problem isn't trying to disable the polling. Setting it to a large number is what I'd eventually end up doing, yes, but my question revolves around the ability to do the webhooking via bitbucket. Is there an easy way to do this without having to programatically generate the PUSH urls for bitbucket?

0
Comment actions Permalink

Sorry, but I don't know. We're just getting onto BitBucket/Git now.

0

Please sign in to leave a comment.