Whilst getting integration tests running as part of a Release Management pipeline within Lab Management I hit a problem that TCM triggered tests failed as the tool claimed it could not access the TFS build drops location, and that no .TRX (test results) were being produced. This was strange as it used to work (the RM system had worked when it was 2013.2, seems to have started to be issue with 2013.3 and 2013.4, but this might be a coincidence)
The issue was two fold..
Permissions/Path Problems accessing the build drops location
The build drops location passed is passed into the component using the argument $(PackageLocation). This is pulled from the component properties, it is the TFS provided build drop with a \ appended on the end.
Note that the \ in the text box is there as the textbox cannot be empty. It tells the component to uses the root of the drops location. This is the issue, as when you are in a network isolated environment and had to use NET USE to authenticate with a the TFS drops share the trailing \ causes a permissions error (might occur in other scenarios too I have not tested it).
Removing the slash or adding a . (period) after the \ fixes the path issue, so..
- \\server\Drops\Services.Release\Services.Release_184.108.40.20679 – works
- \\server\Drops\Services.Release\Services.Release_220.127.116.1179\ – fails
- \\server\Drops\Services.Release\Services.Release_18.104.22.16879\. – works
So the answer is add a . (period) in the pipeline workflow component so the build location is $(PackageLocation). as opposed to $(PackageLocation) or to edit the PS1 file that is run to do some validation to strip out any trailing characters. I chose the later, making the edit
$buildDirectoryParameter = [string]::Empty
# make sure we remove any trailing slashes as the cause permission issues
$BuildDirectory = $BuildDirectory.Trim()
$BuildDirectory = $BuildDirectory.Substring(0,$BuildDirectory.Length-1)
$buildDirectoryParameter = "/builddir:""$BuildDirectory"""
Cannot find the TRX file even though it is present
Once the tests were running I still had an issue that even though TCM had run the tests, produced a .TRX file and published it’s contents back to TFS, the script claimed the file did not exist and so could not pass the test results back to Release Management.
The issue was the call being used to check for the file existence.
As soon as I swapped to the recommended PowerShell way to check for files
it all worked.