0
votes

I am trying to configure Cruise control 1.8.5 to connect to Visual Studio Online to get the source to build and run tests, however whatever I do I always get the error 'TF30063: You are not authorized'

I have copied over tf.exe and required DLLs to the build machine as per one of the answers here (I would rather not install VS2013 on the build machine if possible, this is just a proof of concept at this point).

I have enabled alternative credentials as per here

This is part of the cc.net config - everything in square brackets has been double checked:

<sourcecontrol type="vsts">
  <server>https://[account-name].visualstudio.com/DefaultCollection</server>
  <project>$/[proj-name]</project>
  <username>[alt-credential-username]</username>
  <password>[alt-credential-password]</password>
  <executable>[path-to-tf.exe]</executable>
  <workspace>[workspace-name]</workspace>
  <autoGetSource>true</autoGetSource>
  <cleanCopy>true</cleanCopy>
  <force>true</force>
  <deleteWorkspace>true</deleteWorkspace>
</sourcecontrol>

I have tried my normal credentials, the alternative credentials, and even ##LIVEID##[alt-credential-username] as mentioned here

I always get:

ThoughtWorks.CruiseControl.Core.CruiseControlException: TF30063: You are not authorized to access https://[account-name].visualstudio.com/DefaultCollection

Note that I am able to connect manually from the build machine, e.g. running the following authenticates successfully and displays the expected directories under source control:

tf.exe dir /folders /server:https://[account-name].visualstudio.com/DefaultCollection "$/[proj-name]" /login:[alt-credential-username],[alt-credential-password]

(this works from both admin and non-admin cmd)

I also tried to run this to get a 'service account' however it crashes for me on Windows 7 x64

I have seen this however as I can manually connect using cmd/tf.exe I am assuming that tf.exe now does support alternative credentials...

I will probably try Team Explorer Everywhere 2013 tomorrow, although I'd rather avoid this due to it being Java based which I have no problem with apart from it's just another dependency / step in the setup.

Any tips/suggestions appreciated, as I'm out of ideas at this point!

UPDATE: Using fiddler as suggested shows the following

tf.exe get from the command line is sending two requests:

1)

https://icb.visualstudio.com/DefaultCollection/VersionControl/v5.0/repository.asmx

soap body:

ReconcileLocalWorkspace [ xmlns=http://schemas.microsoft.com/TeamFoundation/2005/06/VersionControl/ClientServices/03 ]

with values for workspaceName, ownerName, pendingChangeSignature and maxClientPathLength

2)

https://icb.visualstudio.com/DefaultCollection/VersionControl/v5.0/repository.asmx

soap body:

Get [ xmlns=http://schemas.microsoft.com/TeamFoundation/2005/06/VersionControl/ClientServices/03 ]

with values for workspaceName, ownerName, requests, maxResults and maxClientPathLength

However CC is sending this request twice:

https://icb.visualstudio.com/DefaultCollection/Services/v1.0/Registration.asmx

soap body:

GetRegistrationEntries [ xmlns=http://schemas.microsoft.com/TeamFoundation/2005/06/Services/Registration/03 ]

with toolId=vstfs

1
Interesting! Could you capture a fiddler trace and see what the difference is between what your command-line tf is doing versus CruiseControl's? Can you log the exact command executed by the CruiseControl.NET plugin?Edward Thomson
I realised while playing around that it would make more sense to try a command line (manual) get, and it appears I need to create a workspace first, which I did and am able to get latest. However fiddler shows different requests than what CC is making. I have updated above.Nick Baker

1 Answers

1
votes

Short answer: Run the cruise control .net service as the same user you used to create the workspace (not the local system account).

Details: I ended up getting the cruise control .net source, and attaching a debugger to see exactly what tf command was generating the error.

The process info that was failing:

Executable = "...tf.exe"
args = {dir /folders /server:https://[account-name].visualstudio.com/DefaultCollection "$/[proj-name]" /login:[alt-credential-username],[alt-credential-password]}
workingDirectory = "[valid-working-dir]"

Running this command manually worked fine - which led me to check the cc service properties, which were set to log on as Local System Account. I updated this to log on as the same (Windows) user that I used to create the workspace and this fixed the problem.

I can only assume that tf.exe is doing something clever with accounts/credentials or maybe it's just that workspaces are tied to particular windows logons?

Thanks to Edward for suggesting I fiddle with fiddler.