How do I set the VCS timeout period, or set a schedule for build activity?

We have a Perforce SCM server that is taken down daily for about four hours for "routine maintenance". Unfortunately, a build for us often starts about an hour before the repository is taken down, and an entire build of all our projects may take several hours. So, clearly, when the build configurations are trying to check in or check out, they fail and cause a cascading failure of configurations and many error reports.

Is it possible/advisable to set the timeout period for source control operations to a very long period, say 6 hours? (I'm assuming that TC retries VCS operations periodically during this timeout period?). If so how do I do that in the Windows version? I've read about the -Dserver.execution.timeout=? flag, but I'm not sure where I need to apply this switch. To the agent service command line? Or in some configuration file? Does it have to be passed manually as an argument when starting the server? If so how does the setting survive reboots of the build machine? etc.

Alternatively, is it possible to set a schedule for all build configurations or an agent in general such that builds won't start during certain hours of the day and will remain queued, and we won't get so many builds failing for no other reason than the SCM being offline?

9 comments
Comment actions Permalink

Wayne,

There is no dedicated feature for automatic disabling of build configuration triggering by schedule. You may file a feature for this.

This is only actual if a build is started by VCS checking and you have build triggers enabled that later trigger a builds while the VCS server is down. In all other cases, scheduling can probably be adjusted not to start builds during VCS unavailability.

For now I can only recommend to write a TeamCity Java plugin that will stop running builds during your maintenance window. It can be based on TeamCity sample plugin that has "pause queue" button.

0
Comment actions Permalink

Yegor,

How about the VCS timeout option? Can it be set to a very long timeout? Does TC retry periodically during this timeout period?

0
Comment actions Permalink

We don't have any Java expertise here, and I can't quickly make any sense of the sample plugin. Is there a simple, programmatic way to enable/disable an agent? I don't need any screens or pages in TeamCity -- just direct access to the agent to turn it off and on from Windows Task Scheduler. I guess I could just stop the service, but I'm not sure what the implications of that would be on TeamCity.

UPDATE: It seems that simply stopping the service doesn't cause any problems -- TC just shows the agent as "disconnected". So I think a couple of Powershell one-liners in Task Scheduler should get me what I need.

0
Comment actions Permalink

Not sure what you mean by VCS timeout...
"Checking for changes interval" option affects how often TeamCity goes to VCS to get the changes, but this only affects how quickly TeamCity detects change after a commit. And on build start TeamCity checks for changes anyway.

0
Comment actions Permalink

You can stop the agent and then start it later - it's OK with the server. With command line you can even stop the agent immediately or after the current build finishes.
You can also stop TeamCity server - should work fine except for the known issue.

0
Comment actions Permalink

How would I determine that the agent is currently busy, from a script?

0
Comment actions Permalink

The timeout I'm referring to is the one that I seem to be able to specify with -Dserver.execution.timeout=?

I just don't know who's parameter that is.

I imagine that when TeamCity tries to communicate with a source code control system, it opens a network port to get a connection, and retries until [server.execution.timeout] seconds has elapsed, and then errors out. Is that correct? If so, I just need to know where to type the characters -Dserver.execution.timeout=[6 hours]

If this isn't the way it works, I have to give up on a long timeout and go to plan B, which is a script which stops and restarts the agent on a schedule.

0
Comment actions Permalink

Wayne,

You probably mean "-Dteamcity.execution.timeout". This is internal JVM property that indeed can be used to change the time that TeamCity waits for launched externals processes to finifh. As Perforce integration calls "p4" binary, this will affect perforce connections too. However, changing the property will affect other externlas tools execution. Moreover, you can get 6 hours "hanging" when external tool indeed hangs, so it's up to you whether this method suits you or not.

If you want to specify the property, you need to do that as server JVM option, see the doc for details.

0
Comment actions Permalink

There is no way to easily determine that... Feel free to post a feature request if you really need this.
However, if you run agent via command line, when you execute "agent stop" command the agent will exit after the current build finishes. (to stop agent immediately cancelling the build, use "agent stop force" command.

0

Please sign in to leave a comment.