TestStand Deployment Tool Problem

[Captain_Jack]

I think that I've uncovered an issue with the TestStand Deployment Tool for version 4.1. We seem to have a problem where the .tsd file is not properly storing the destination information. Everything is fine if the .tsd file is located exactly where it was originally created, but if the .tsd file is moved to a different location, then the deployment does not function properly. We found this because we use ClearCase to manage our software configurations, and it can involve the different paths for different view configurations. I've been able to rule out ClearCase as a problem here, as I've been able to recreate the issue with an example deployment configuration outside of ClearCase.

I created a Test_Deployment_workspace.tsd, as well as a project file that uses some TestStand examples that I created in the 'C:\Temp\Test_Deployment' folder. If you run this from there it shows the correct configuration as was originally created. If that file is then moved to another location, such as a shared volume or other directory structure and run, it does not show the correct configuration.

I've included the .tsd, the .tsw, and the .tpj files needed to reproduce this issue. I've also included a document showing the differences when run from different locations.

Any suggestions on how to configure and/or use the deployment tool differently (.ini configuration settings?) so that we can get our CM people to reliably recreate deployments would be greatly appreciated. I current work-around that we will attempt is to make sure that the file is moved to a specific location before it is executed, but that's not an ideal solution.

Thanks,

-Jack

[RayFarmer]

Hi Jack,

When you open the deployment file in any directory other than c:\Temp\Test_Deployment then the path to the tsw file is incorrect on the System Source Tab.

If you change the path to make it the correct location then your Distributed Files will be correct, as per your attached document.

for example  I saved your attachment and placed your project which extracted out as ..\Test_Project\.. into c:\Temp

When I open the tsw file the workspace file path on the System Source Tab was still C:\Temp\Test_Deployment\Test_Deployment_workspace.tsw

But the actual path was c:\Temp\Test_Project\....

When I corrected the Workspace File Path to c:\Temp\Test_Project\... the Distributed Files showed the correct file structure.

I hope this helps you.

Regards

Ray Farmer

[Captain_Jack]

Ray,

Thanks for looking at this and at least confirming that it's not my imagination or my TestStand configuration. Unfortunately, we'd prefer a solution that will work without having our CM people have to edit the build before running it.

I followed your thought process, and extracted it to a folder that was three deep from the root drive, and it did indeed reset the distributed files, but not correctly in my case. Instead of showing the distributed files going to the Target, they where going to the Action location via the Installation Destination (TestStand Public Documents Directory) and added the Test_Project.tpj and Test_Deployment_workspace.tsw to the Target location.

I then used your exact path structure (really just renaming the folder in Temp), and it still did not work properly.

I think that this is one case where it appears the use of relative paths is not helping the situation.

Bottom line is that we can't currently trust the deployment configuration file to give us repeatable results when used by different computers using different ClearCase view configurations (Engineering view vs. CM release view).

-Jack

[RayFarmer]

Hi Jack,

You are right. I was working in the same directory, c:\temp. The only thing that was different was the directory name in which the workspace files were situated.

I shifted it all to another directory in this case it was C:\MyTemp. 

I changing the path to c:\MyTemp.....in the Source window. Then switching to the Distributed Files window and after Analyzing, the path structure was total different. Instead of Target, it was TestStand Public Documents Directory followed by Examples etc.

By changing the Installtion Destination back to Target (In my case Its called Installation Directory) then changing the Installation Destination subdirectory of Examples too

Temp\Test_deployment\Examples will get back to the desired destination structure.

But this is not right that you have to modify the deployment file.

You would have to extract your files to exactly the right locations eg C:\Temp so you could build your deployment image otherwise you would have to modify the deployment setting as I have mentioned above.

Regards

Ray

[RayFarmer]

Jack,

I made sure c:\temp\test_deployment didn't exist. (before I still had files in C:\Temp\Test_Deployment)

I then opened the deployment file found in C:\MyTemp\Test_Deployment.

This time the Workspace File Path was correct, i.e. C:\MyTemp\Test_Deployment\Test_Deployment_workspace.tsw

Selecting the Distributed Files Tab, and after Analying, the File Structure was Installation Directory with the Installation Destination SubDirectory as C Still not right

Regards

Ray

[Captain_Jack]

Ray,

Thanks for continuing to help with this! It's not explicitly clear to me; are you seeing the odd behavior with the Deployment tool from your last post? I think you are seeing something odd, but I want to be sure.

I found a DeploymentUtilityOptions.ini file in the Cfg directory, and I changed Do_Not_Update_Projects_or_Sequences=TRUE (from false) but that didn't do anything. I am wondering if there are any other hidden properties that might be available in this INI file... Anyone from NI care to weigh in?

-Jack

[RayFarmer]

Hi Jack,

Yeah, I believe I am confirming what you are getting and that the only way to ensure you create the right deployment image is to extract everyting to the same location as there were created.

Otherwise you have to edit the Depolyment Tool file to get back to the right file structure.

Regards

Ray

[Captain_Jack]

Thanks Ray.

I appreciate you confirming what I've been seeing.

It's good to know I'm not alone in the asylum...

-Jack