Using the Vault CLI not working from service.

[Tony]

I have the 3.0.6 build of Vault running on Windows Server 2003 SP1 and I am using Active Directory authentication.

I am setting up Vault with CCnet, NAnt, et. all. I have built this type of infrastructure several times in the past, but never with Vault, so I started small and made sure that I had a Vault CLI that would do what I wanted. This is my command, below:

Code: Select all

vault.exe GET $/Customer/Project -repository ClientProjects -destpath D:\BuildWork\Customer\Project -host devbuild.mycompany.com -username AD_Domain_User -password PWD -makereadonly -merge overwrite -setfiletime checkin -performdeletions removeworkingcopy

When I run this manually from within the command window, it works fine.

Next, I integrated this into NAnt and started calling NAnt from the command line. I have it spitting out the Vault command line that it builds, and it is identicle to the one above (and works the same).

Now, when I call the NAnt script from CCnet (a Windows service running under the Local System account with no "desktop interaction"), the exact same Vault command line is spit out by NAnt, but the error returned is

Code: Select all

'vault.exe' failed to start.

The exact same process calling the FxCop CLI application works fine.

Is there something I am missing when it comes to running Vault.exe from a Windows service? Granted, it has no user context when running as the Local System account, but does it need one? On a whim, I tried running the CCnet service under the valid AD account of the same user that I used when installing the Vault service and it made no difference.

On an unrelated, side note, are you working on and/or have an ETA on a fully integrated CCnet source code provider block? It would be nice to not need these gyrations when working with Vault.

[jeremy_sg]

I actually does matter if the command line tool is running as a real user or the system user. The client needs to write cache files to its application data directory. The failure should have logged more information than just "vault.exe failed to start", including what the error was. Do you see more information in the CC.net log file or by putting Nant/CC.net in verbose/debug mode?

Vault is already fully supported in CC.net. An example source control block is:

Code: Select all

<sourcecontrol type="vault">
      <executable>c:\program files\sourcegear\vault client\vault.exe</executable>
      <username>[BuildUser]</username>
      <password>[Password]</password>
      <host>www.mydomain.com</host>
      <repository>[Repository]</repository>
      <folder>$/CurrentCode</folder>
      <ssl>False</ssl>
    </sourcecontrol>

Also, I'm working on documenting everything that needs to be done to set up Vault and continuous integration, but I have to squeeze it in around coding for 3.1.

[Tony]

It actually does matter if the command line tool is running as a real user or the system user. The client needs to write cache files to its application data directory.

Ah ha! And, in retrospect, I should have thought of this, given that part of the installation for the product was to first log onto the server locally as the account which you planned to use for the Vault service. Gotcha.

Do you see more information in the CC.net log file?

Yes, but as it turns out, I have a problem totally unrelated to Vault (which I doubt surprises you ), but Vault just happened to be the first step in the process, so it "barfed" first. Perhaps you have some insight, given your work with CCnet?

I have the locations of my various CLI tools (so far that's Vault, NAnt & FxCop) in the system's PATH variable. I can run any or all of these from the command window without issue and when I dump the PATH value, it contains the values I expect.

The problem, as it turns out, is that when I use the CCnet service and I do not use a FQ path to my EXEs (Vault, NAnt or FxCop), it throws the "can't find your program" embolism. This is the case even when I enable "interact with desktop" or set the CCnet service to run as the same user that I used for my Vault service. Should a service have access to the system PATH? Any ideas?

Vault is already fully supported in CC.net.

You are correct, of course. I should have been more specific. I am using that CCnet task to check for version changes. What I was talking about was a task (either for CCnet, NAnt or both) that would take care of extracting the files out of Vault once a change was discovered and exporting XML that CCnet could merge into its report at the end.

Also, I'm working on documenting everything that needs to be done to set up Vault and continuous integration, but I have to squeeze it in around coding for 3.1.

What? You have more than one task! You should quit.

Here are the settings I am using, in case it's of value to you or someone else. Or maybe you'll see somewhere that I'm going wrong.

In the ccnet.config file, I have the following:

Code: Select all

<nant>
    <executable>nant.exe</executable>
    <buildArgs>-find -D:vault.path=$/Customer/Project -D:vault.repository=ClientProjects -D:solution.name=TheProjectSolutionFile</buildArgs>
    <nologo>true</nologo>
    <buildTimeout>300000</buildTimeout>
</nant>

In the NAnt.exe.config (which is global to all builds), I have the following:

Code: Select all

<properties>
    <!-- properties defined here are accessible to all build files -->
    <!-- <property name="foo" value = "bar" readonly="false" /> -->
    <property name="vault.client" value="vault.exe" readonly="true" />
    <property name="vault.host" value="devbuild.mycompany.com" readonly="true" />
    <property name="vault.user" value="AD_User" readonly="true" />
    <property name="vault.password" value="UserPwd" readonly="true" />
    <property name="vault.cmdline" value="-host ${vault.host} -username ${vault.user} -password ${vault.password} -makereadonly -merge overwrite -setfiletime checkin -performdeletions removeworkingcopy" readonly="true" />
</properties>

In the NAnt default.build (which is in a top-level directory and the default build file if the project doesn't have one of its own), I have the following:

Code: Select all

<target name="update">
    <exec program="${vault.client}" failonerror="true" timeout="300000"
				commandline="GET ${vault.path} -repository ${vault.repository} -destpath ${ccnet.working.directory} ${vault.cmdline}" />
</target>

[jeremy_sg]

There are nant tasks for vault to do all sorts of things. You can find them and the documentation for them at http://vaultpub.sourcegear.com/build

[Tony]

There are nant tasks for vault to do all sorts of things.

This is phenominal! I've been looking for just this sort of thing all week.

Oh, and on a semi-related note as an update to the above issue, the thing I am running into is that the CCnet service, regard;ess of what user account it is running under, does not have access to an expanded PATH variable. So, when I execute an "echo %path%" command from a task within CCnet, running the command line manually gets me an expanded PATH, but running the same configuration file from the service (as Local System or as me) gets a PATH with unexpanded environment variables.

I still have no idea why, mind you, but it is true.

Thanks again for the tasks. I'm looking forward to using those.

Tony

[Tony]

I replaced my EXEC task with your vaultgetfile task and it worked like a champ! I have one question, if I may. My exec task was appending the following switches to the end of the vault.exe command line (along with all the usual ones as well):

Code: Select all

-makereadonly -merge overwrite -setfiletime checkin -performdeletions removeworkingcopy

Which of these options are set by default and which, if any, can be specified or passed in to the task?

Again, great work!

Tony

[jeremy_sg]

1. performdeletions only matters when destpath is not specified. This isn't the clearest thing to understand, but the destpath argument essentially means that you do not want to use the regular working folder, and no working folder information will be saved for this get. Since there's no working folder information stored, performdeletions doesn't apply, since it applies repository deletions to the working folder. Also note that specifying the destpath parameter means that every file will be downloaded, as opposed to just updating the working folder with the files that have changed since the last get.

2. The vaultgetfile task defaults to MakeWritable. (and you can't currently override it (unless you want to edit the source, which you can))

3. The task also defaults to Current, and you can't override it (unless you want to edit the source, which you can).