September 11, 2009

More on Surround SCM Triggers – Executables

Surround SCM
This post is a follow up to my first one about Surround SCM triggers and executables. A few years back, while still working in support I conducted an experiment to really comprehend how executables work when they are launched by Surround SCM as part of a trigger. I wanted to know "where" the script runs, what it considers to be the "current" directory, and whether it depended on the location of the executable. Following is the internal article I wrote back then.

The Set Up

I have a workstation that I use for most of my work. The machine name is "Cremer280". Next to me, I have another computer that is running Windows Server 2003 SBS. The name of this machine is "fredsbs". This machine has its own domain called "Wysicorp". I use it as my server for testing and support cases. On fredsbs I have the Surround SCM Server running as a service. The service runs under Local System Account. On my workstation (Cremer280), I have a folder "D:MY_SHARE". As the name implies, I have enabled sharing (I gave "everybody" "full control"). The share name is "MyShare". When I log in to fredsbs, the way I access my shared folder on my workstation is by using \Cremer280MyShare as the path. On my workstation, I created a MS DOS batch file in "D:MY_SHARE". The batch file only has one line: "dir > C:base.txt" The name of the batch file is "base.bat". I opened the Surround SCM client on my workstation. I selected "Tools">"Administration">"Triggers" and added a new trigger. I picked a specific branch and repository, and chose "check in" as the event. I then specified the script/executable to "\Cremer280MySharebase.bat". Note that, even though I am logged in and running the client on "Cremer280", I have to specify the path the same as if I was logged in on the server itself. Had I entered "D:MY_SHAREbase.bat", Surround would look for a D: drive on the server and the batch file would never execute.

Test Results

I then ran some tests by checking out, editing, and checking in files in the repository and branch I had specified in the trigger. Here are some observations: Local System Account issues: The batch file did not execute at first. The reason is because I have the Surround SCM server service under "Local System Account". To test this, I logged into the fredsbs machine, stopped the server, waited until it stopped, and then browsed to C:Program FilesSeapineSurround SCM and double-clicked on "Surround SCM Server.exe". This started the Surround SCM Server as an application, not a service. More importantly, instead of the server running as "Local System Account", it was running as the user that I logged into the server as ("WysicorpAdministrator"). From this moment on, the script executed every time I checked in a file. Local System Account has some limitations to accessing network shares. In the services properties window, under the "log on" tab, you can select "Local System Account" or another account for the service to run as. You would need to create a user account with enough privileges to access the network. If you have no choice but to use Local System Account, then you are basically limited to having to place the script/executable on the server itself. In this example, I would have to set the script/executable to "C:base.bat" and place the batch file on the root of the C: drive on the server. Output of batch file: If you recall, the batch file only contained the command: "dir >C:base.txt" That leaves us with two questions:
  1. Which directory will the C:base.txt file list?
  2. Which C: drive will it save the file in?
First of all, the file was saved on the C: drive of the server. Also, the content of the file was the directory listing of all files and folders found on the C:Program FilesSeapineSurround SCM directory on the server. So the batch file 'ran' on the same directory that the Surround SCM Server executable is located. However, this is because I had the Surround SCM Server running as an application. I then made some changes to the trigger and batch file and was able to determine that, if the Surround SCM Server is running as a service, the contents of the output file is a directory listing of the root of the C: drive on the server. The location of the batch file itself did not matter. One last thing I did: I changed the batch file command to: "dir >\Cremer280MySharebase.txt". I ran the Surround SCM Server as an application and logged in and did a check in. The "base.txt" file was created on my shared folder and the contents were the same as when it was created on the C: drive of the server.

In Conclusion

So the main thing to keep in mind is that the script/executable will always 'run' on the server. If the server is running as an application it will 'run' on the directory where the Surround SCM Server executable is located. If the server is running as a service, it will 'run' on the root of the C: drive of the server. The directory that the script/executable 'runs' on is the 'current directory' for the script/executable. The script/executable can be located a different machine from the server, but the path that you specify in the trigger must be as if you are logged into the server itself. While this test was done in a Windows environment, the same principles should apply if you are in a different environment.