Publishing Test Results in TeamBuild

Few weeks ago, I worked with TSDT product team in setting up infrastructure for publishing test results into our TeamBuild dogfood server. This is one of the coolest features offered by TeamBuild and TSDT integration. The thought behind this feature was to allow testers to publish regression test results etc against a particular build. The build report includes all these test reports which would help the managers to gauge the quality of the build from one single source.

Walkthrough

1. The user needs to get “Publish test results” permission on the team project as shown below. All contributors have this permission set in team projects created using ‘MSF Agile’ and ‘CMMI’ process templates.

2. Open test results in Visual Studio to open them in “Test Results” window and click on the “Publish” button. This button is slightly undiscoverable, so I’m attaching a picture to help you.

3. Select the “Associated build number” and “Build flavor”, select include code coverage data checkbox in case these runs have CC data and you want to publish them and click OK.

4. You are done! The build report will now include this test report as well.

Here are some details how this is internally implemented and the permissions required on the build drop share. IMO, these are important to know so that users inadvertently don’t give additional permissions which might compromise the security. Read on…

How does publishing work from client?

1. Visual Studio client (the publishing client) sends a publish request to the Team Foundation Server publishing web service

2. The publishing web service authenticates the user against ‘Publish Test Results’ permission

3. It then creates an appropriate testresults folder under the build drop location and gives NTFS full control access to the publishing client

4. The publishing client copies the test results to the drop location

5. Once the copying is done, the publishing web service revokes the NTFS permissions that were granted before.

 

Permissions required on the build drop share

The users need to be granted ‘Full Control’ at share permission level.

This is required for (4) above to work. Even though the user has been granted full control, the non-read access for individual users can be controlled using NTFS permissions as described below. IMO, the recommended permissions are:

1. Unselect ‘Allow inheritable permissions from the parent…’ so that this folder does not inherit permissions from its parent folder (select properties of the folder à select Security Tab à click on “Advanced” button) as shown below.

2. Remove all permissions granted to <Machine>\Users (by default all authenticated users are part of this group). Give ‘Read’ permission only (for e.g., a default folder will have the highlighted permissions set which will need to be removed) as shown below.

Namaste!