Trying to create a repository entry for one of my SourceGear Vault servers and it is failing the validation check with "Error communicating with Vault server." We do require HTTPS to connect to it, and there isn't an option to use SSL when connecting.
After temporarily disabling SSL on the Vault server, it’s at least getting further along. But now it’s throwing this error:
Repository SGV-Platform cannot be initialised: Running vault.exe failed with return code: -1 and error output:
System.Exception: The working folder state information for D:\Continua\Rc\5731ddfc\Platform.…\zip is incompatible with this version of Vault. Please choose a different working folder path. The specific compatibility exception was: Could not detect the file type in the supplied stream.
at VaultClientIntegrationLib.GetOperations.ProcessCommandGet(String objectPaths, GetOptions getOptions)
at VaultCmdLineClient.VaultCmdLineClient.ProcessCommand(Args curArg)
at VaultCmdLineClient.VaultCmdLineClient.Main(String args)
False
There are two issues being raised here, but only one of them applies here, I think.
1. Why is it trying to get the source onto the Continua server itself if there’s no agent installed on it?
2. Why is the Vault client throwing that error in the first place? (This one is probably a SourceGear issue.)
Hi Michael,
We’ve added an option to the Vault repository to enable SSL connections. That’ll be in the next build which Vincent will post to the forums when it’s ready.
> 1. Why is it trying to get the source onto the Continua server itself if there’s no agent installed on it?
Ben is currently working on the repository wiki page which explains this, it is available here http://wiki.finalbuilder.com/x/mgEK.
> 2. Why is the Vault client throwing that error in the first place? (This one is probably a SourceGear issue.)
This seems to be a common Vault issue, see http://support.sourcegear.com/viewtopic.php?t=4922. If the problem persists, or comes back, after performing the cache cleaning, please let us know.
Cheers,
Paul.
There’s no cache to clean. The Vault client was installed on the server, but has never been used. Which may be the actual problem. I will investigate a bit and see what I can come up with.
There is still some weirdness here, even after getting things set up.
Is it possible to dump the vault.exe command line being used into the error report in the log so I can see what it’s actually trying to do?
For the record the error is this:
Checking Repository MMS-Platform failed with error Running vault.exe failed with return code: -1 and error output:
System.Web.Services.Protocols.SoapException: 1209 : FailInvalidObjID
at VaultClientIntegrationLib.ServerOperations.ProcessCommandHistory(String objectPath, Boolean recursive, DateSortOption dateSort, String excludedUsers, String excludedActions, String beginDate, String endDate, String beginLabel, String endLabel, Int64 beginVersion, Int64 endVersion, Int32 rowLimit, String commentFilter)
at VaultClientIntegrationLib.ServerOperations.ProcessCommandHistory(String objectPath, Boolean recursive, DateSortOption dateSort, String excludedUsers, String excludedActions, String beginDate, String endDate, String beginLabel, String endLabel, Int64 beginVersion, Int64 endVersion, Int32 rowLimit)
at VaultCmdLineClient.VaultCmdLineClient.ProcessCommand(Args curArg)
at VaultCmdLineClient.VaultCmdLineClient.Main(String args)
False
Based on a little snooping with Process Monitor (www.microsoft.com/sysinternals) it appears it is looking for ObjID 466392. Which doesn’t actually exist. According to the Vault GUI the highest value is 135843. If I change the command line that Continua is using to use the 135843 value it is nice and happy.
It does appear that the 466392 value is actually being handed back by the Vault.exe history command in the returned XML. I cannot explain the discrepancy, but I have asked the nice folks over at SourceGear to.
Hi Michael,
Thanks for putting the effort in to getting this resolved.
With regards to seeing what we’re passing to Vault, you’ll need to adjust the logger settings in the app.config and use the Continua.Diagnostics.exe application to see what is being called. We’ll be updating the beta builds to have ‘debug’ logging enabled by default, but for the current builds you’ll need to…
a) Open C:\Program Files\VSoft Technologies\ContinuaCI\Server\Continua.Server.Service.exe.config in notepad
b) Change (approx line 31) level to “Debug”
c) Save file then restart the Continua Server service.
d) Run C:\Program Files\VSoft Technologies\ContinuaCI\Server\Continua.Diagnostics.exe
Quick tip for the diagnostics app is that you can double click the text to pause logging, then double click to resume.
Let us know how you go with SourceGear
Hi Michael,
There’s a couple of ways to see what the command line being sent to Vault is, without using Process Monitor.
As Paul mentioned, you can run the Diagnostics app, but that can be a little tricky when trying to catch/search for a specific entry.
I’ve just added a file logger, which will be enabled by default (and set to Debug level for the beta). It will create a log file per day in C:\ProgramData\VSoft\Continua\Logs, with old logs being cleaned up after 7 days. It should be included in the next beta build.
Thanks for chasing up re the strangely high value with SouceGear. Please let us know when they get back to you.
Cheers,
Ben
The XML output generated by the ‘VAULT HISTORY’ command has an attribute called ‘txid’ which is the unique transaction ID for that repository.
Unfortunately when y’all try to run VAULT HISTORY -beginversion and reference a transaction ID, Vault throws an error because the transaction ID value is not the version number wanted by that switch.
I think, for what is being attempted here using -begindate would be a better option.
Hi Michael,
You’re correct, we should be using date ranges rather then the TXID, I’m not sure why the FinalBuilder Server vault trigger code wasn’t re-used here, as it used dates.
Will let you know when the changes are in the beta.