Multiple simultaneous builds

We've recently moved a lot of our builds to use GitHub (Enterprise) webhooks so we could cut down our Git poll interval and it's impact on our Git server.  But for some reason, our webhooks can at times be a little slow starting a build.  And the problem there is if the Git poll and the webhook overlap, it'll kick off 2 builds for the same configuration.  I did some searching and I saw some mention of the "Limit the number of simultaneous running builds" setting which would probably help.  But we have almost 100 build configurations and I really don't want to go change all of them individually and rely on other developers to set that setting correctly for new builds.  I've also seen mention of the source control "quiet period" setting but the default for a new build appears to be to ignore the global setting so most of our builds don't use it.  And there again, I'd really like to avoid a solution where I have to change every build now and in the future.

Is there an easy fix here?

Thanks,
tim

3 comments
Comment actions Permalink

Hi Tim,

It is not possible to configure "Limit the number of simultaneously running builds" per server. We have the related request https://youtrack.jetbrains.com/issue/TW-13222, please vote. You can write a script, that adds option <option name="maximumNumberOfBuilds" value="xx" /> to the build configuration .xml file in TC Data Directory.
You need to select "Use default value (xx seconds)" when creating VCS trigger ("Do not use" is set by default).
I'm not sure that these settings will help. As far as I understand the problem is the following: if webhook is slow, VCS trigger fires the build. Then as far as webhook does not know anything about builds in TeamCity it fires the same second build. So if you limit the number of simultaneously running builds, the build will be triggered but will wait in the queue. If you configure quiet period, you actually delay build triggered by VCS trigger, so it waits for webhook to fire. Do you really need both webhooks and VCS trigger?

0
Comment actions Permalink

Thanks for the response, I did go vote for that issue.  I would like to say that we don't need both but the simple fact is that I don't trust the webhook enough!  But we had to go to webhooks because of what I said in my post, that it was impacting our GitHub Enterprise server.  And of course push vs. pull just seems better.

0
Comment actions Permalink

Also, I did just run a script to change all of the build configs to use the default quiet period.  It's definitely not an ideal solution (even if it does work) since any future builds will use the default "no quiet period" setting.

0

Please sign in to leave a comment.