3

I have configured TeamCity to work with our TFS repo. I have configured the VCS Root and used the "Test Connection" to ensure that the settings are all correct. When I run a build it gets to the "Updating sources" and just hangs there. Here's the build log.

[13:33:45]Collecting changes in 1 VCS root
[13:33:47]Clearing temporary directory: D:\TeamCity\buildAgent\temp\buildTmp
[13:33:47]Publishing internal artifacts
[13:33:48]Using vcs information from server. Reason: no revision information for build configuration "Build Development trunk" and checkout directory D:\TeamCity\buildAgent\work\db23c120e1319dcb on agent
[13:33:48]Clean build enabled: removing old files from D:\TeamCity\buildAgent\work\db23c120e1319dcb
[13:33:48]Checkout directory: D:\TeamCity\buildAgent\work\db23c120e1319dcb
[13:33:48]Updating sources: server side checkout (1m:21s)
[13:33:48][Updating sources] Will perform clean checkout
[13:33:48][Updating sources] Clean checkout reasons
[13:33:50][Updating sources] Building and caching clean patch for VCS root: Development trunk

The checkout folder is empty. Any ideas?

EDIT

I've written a Windows batch file that gets the code out from TFS rather than using TeamCity to do this. My batch file runs perfectly when run from the Windows command prompt but fails when run from TeamCity. I am using the fully qualified path to TF.EXE because TeamCity doesn't seem able to find TF.EXE (even though the path has been added to the PATH environment variable).

My batch file correctly configures the TFS workspace before trying to GET the source code. But it still fails.

"C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\tf.exe" workspaces /collection:http://code-srvr1:8080/tfs/DefaultCollection
"C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\tf.exe" workspaces /s:http://code-srvr1:8080/tfs/DefaultCollection
"C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\tf.exe" workfold //fails!!
"C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\tf.exe" get $/MSM\Development\Trunk /force /recursive //fails!!

The error I am getting is "Unable to determine the workspace. You may be able to correct this by running 'tf workspaces /collection:TeamProjectCollectionUrl'"

But as can be seen I am already specifying the workspace in the batch file.

Any ideas why these commands work from the Windows command line but fail from TeamCity? How do I get them to run from TeamCity?

DomBurf
  • 2,452
  • 5
  • 36
  • 71
  • How much disk space does the code under your VCS root consume? For large repos I've seen teamcity take time to pull down the code and whilst it's doing that it's not very good at reporting progress. – James Reed Aug 09 '15 at 01:27
  • @JamesReed Thanks. I'll let it run through the morning and see what happens. The repo is 2GB in size. – DomBurf Aug 10 '15 at 07:49
  • Depending on network speed and disk IO, I'd expect a 2GB repo to take maybe an hour or so for a clean build. About 30 mins to copy to the build server, then 30 mins to copy to the build agent. You can speed this up by setting up your builds to use an [agent side checkout](https://confluence.jetbrains.com/display/TCD9/VCS+Checkout+Mode#VCSCheckoutMode-AgentCheckout). – James Reed Aug 10 '15 at 16:31

2 Answers2

1

The solution in my case was to upgrade my Team Foundation Client from 2012 to 2013. There are known timeout issues with the 2012 version and upgrading to 2013 has resolved these.

DomBurf
  • 2,452
  • 5
  • 36
  • 71
0

I had the same issue (TeamCity builds that fetched code from TFS would get stuck indefinitely at the Updating sources stage, blocking the agent).

The solution for me was to make sure that the TeamCity Build Agent ran under the same service account as the TeamCity Server. The server would be able to access the TFS project and instruct the agent to do a build, but the agent itself got stuck when it was not authorized.

When that account mismatch was fixed, it all started working as it should.

As a side note, when the parameter “teamcity.tfs.mode=java” is set, the TeamCity agent does not get stuck, but instead fails with an instructive error message (detailing the current service account name), if it runs under an unauthorized account.

Otto G
  • 670
  • 7
  • 14