TeamCity 2017.1.2 & Vault 10
Moderator: SourceGear
Re: TeamCity 2017.1.2 & Vault 10
What if you tried a test using http://vaultdemo.sourcegear.com | Initial Repository | guest2 | guest 2 ?
Do you have HTTP disabled? Any chance you can try plain HTTP?
If it works in either case with HTTP, please give that first link a read. If HTTPS is going to be used, you're going to have to add configure the keystore of the Java Runtime installation. AFAIK, that has always been a requirement of using SSL with Vault's Java based libraries.
Do you have HTTP disabled? Any chance you can try plain HTTP?
If it works in either case with HTTP, please give that first link a read. If HTTPS is going to be used, you're going to have to add configure the keystore of the Java Runtime installation. AFAIK, that has always been a requirement of using SSL with Vault's Java based libraries.
Jeff Clausius
SourceGear
SourceGear
Re: TeamCity 2017.1.2 & Vault 10
No, but we added that to increase memory to deal with very large repositories just in case - https://confluence.jetbrains.com/displa ... CityServerWere you getting errors previous to setting TEAMCITY_SERVER_MEM_OPTS? I don't have that set.
Jeff Clausius
SourceGear
SourceGear
Re: TeamCity 2017.1.2 & Vault 10
I tried the vautldemo and got the same error as I do with my own Vault server.jclausius wrote:What if you tried a test using http://vaultdemo.sourcegear.com | Initial Repository | guest2 | guest 2 ?
Do you have HTTP disabled? Any chance you can try plain HTTP?
If it works in either case with HTTP, please give that first link a read. If HTTPS is going to be used, you're going to have to add configure the keystore of the Java Runtime installation. AFAIK, that has always been a requirement of using SSL with Vault's Java based libraries.
HTTP redirects to HTTPS. I can check the keystore but I doubt that's the issue because 1) My TC worked with Vault 9.0 and stopped after upgrading to Vault 9.1 (until I put the 9.0 CLC back). and 2) the Java CLC in the lib folder actually works fine from the TC server when I try the command line and connect to Vault over HTTPS.
Re: TeamCity 2017.1.2 & Vault 10
I'm drawing a blank on solving this.
Yesterday we downloaded each Java CLC - http://download.sourcegear.com/VaultPro ... _30736.zip and http://download.sourcegear.com/Vault/10 ... _0_736.zip were downloaded.
Downloaded installed TeamCity 2017.1.3 and a customer downloaded and installed TeamCity 10.0.3 both on Windows Server 2012 R2. After stopping the TeamCity services, we extracted the Vault Java CLC "lib/" sub-directory and placed it in the corresponding TeamCity Data Directory (which is dependent on the version). After we verified it was in place, the TeamCity Services were started.
Using HTTP, we could connect to vaultdemo.sourcegear.com, vaultprodemo.sourcegear.com, and the user was able to connect to their Vault Server using a FQDN. The "Test connection" button affirmed the connection in its dialog.
I don't know what would be different except HTTPS. We'll test an SSL setup in house. It will take a bit as we'll need to provision a VM and setup IIS with SSL. Note, the IIS Server will be required to run the full SSL suite of protocols (SSLv3 and TLS 1.0/1.1).
Yesterday we downloaded each Java CLC - http://download.sourcegear.com/VaultPro ... _30736.zip and http://download.sourcegear.com/Vault/10 ... _0_736.zip were downloaded.
Downloaded installed TeamCity 2017.1.3 and a customer downloaded and installed TeamCity 10.0.3 both on Windows Server 2012 R2. After stopping the TeamCity services, we extracted the Vault Java CLC "lib/" sub-directory and placed it in the corresponding TeamCity Data Directory (which is dependent on the version). After we verified it was in place, the TeamCity Services were started.
Using HTTP, we could connect to vaultdemo.sourcegear.com, vaultprodemo.sourcegear.com, and the user was able to connect to their Vault Server using a FQDN. The "Test connection" button affirmed the connection in its dialog.
I don't know what would be different except HTTPS. We'll test an SSL setup in house. It will take a bit as we'll need to provision a VM and setup IIS with SSL. Note, the IIS Server will be required to run the full SSL suite of protocols (SSLv3 and TLS 1.0/1.1).
Jeff Clausius
SourceGear
SourceGear
Re: TeamCity 2017.1.2 & Vault 10
Well if your TC setup is able to work with Vault, it must be something specific to my server. Both my Vault and TC servers have been upgraded a few times, maybe something got confused along the way.jclausius wrote:I'm drawing a blank on solving this.
Yesterday we downloaded each Java CLC - http://download.sourcegear.com/VaultPro ... _30736.zip and http://download.sourcegear.com/Vault/10 ... _0_736.zip were downloaded.
Downloaded installed TeamCity 2017.1.3 and a customer downloaded and installed TeamCity 10.0.3 both on Windows Server 2012 R2. After stopping the TeamCity services, we extracted the Vault Java CLC "lib/" sub-directory and placed it in the corresponding TeamCity Data Directory (which is dependent on the version). After we verified it was in place, the TeamCity Services were started.
Using HTTP, we could connect to vaultdemo.sourcegear.com, vaultprodemo.sourcegear.com, and the user was able to connect to their Vault Server using a FQDN. The "Test connection" button affirmed the connection in its dialog.
I don't know what would be different except HTTPS. We'll test an SSL setup in house. It will take a bit as we'll need to provision a VM and setup IIS with SSL. Note, the IIS Server will be required to run the full SSL suite of protocols (SSLv3 and TLS 1.0/1.1).
The frustrating thing is that whatever is going wrong the message comes back null. I've pasted all the stack trace TC gives me. I'm not sure i'm reading it right, but this portion sticks out:
Caused by: java.lang.NullPointerException
at clr.runtime.javautils.JavaObjectWrapper.toString(JavaObjectWrapper.java:22)
at clr.System.ObjectStaticWrapper.toString(Object.jvm.cs:89)
at VaultClientOperationsLib.RegistryKeys.GetDefaultAsString(Unknown Source)
Code: Select all
jetbrains.buildServer.vcs.VcsRootVcsException: Error collecting changes for VCS repository '"VaultRepo" {instance id=28, parent internal id=6, parent id=VCS, description: "vault: https://vault.mycompany.com/VaultService"}'
VaultRepo {internal id=28}: Exception occurred while trying to connect to Vault server. See original message below:
null
at jetbrains.buildServer.buildTriggers.vcs.ConnectionStateReporterImpl.reportConnectionFailed(ConnectionStateReporterImpl.java:3)
at jetbrains.buildServer.buildTriggers.vcs.ConnectionStateReporterImpl.reportConnectionFailed(ConnectionStateReporterImpl.java:29)
at jetbrains.buildServer.buildTriggers.vcs.VcsRootChangesLoader$RunLoadChanges.run(VcsRootChangesLoader.java:81)
at jetbrains.buildServer.util.NamedThreadFactory.executeWithNewThreadName(NamedThreadFactory.java:71)
at jetbrains.buildServer.buildTriggers.vcs.VcsRootChangesLoader.loadChanges(VcsRootChangesLoader.java:32)
at jetbrains.buildServer.vcs.impl.VcsChangesFetcher$LoadChangesForRoot.run(VcsChangesFetcher.java:13)
at jetbrains.buildServer.vcs.impl.VcsChangesLoaderImpl$ImmediateFutureExecService$1.call(VcsChangesLoaderImpl.java:1)
at jetbrains.buildServer.serverSide.impl.ImmediateFuture.get(ImmediateFuture.java:59)
at jetbrains.buildServer.serverSide.impl.ImmediateFuture.get(ImmediateFuture.java:68)
at jetbrains.buildServer.vcs.impl.VcsChangesSyncFetcher.waitForTasksToComplete(VcsChangesSyncFetcher.java:125)
at jetbrains.buildServer.vcs.impl.VcsChangesSyncFetcher.doLoadChanges(VcsChangesSyncFetcher.java:28)
at jetbrains.buildServer.vcs.impl.VcsChangesSyncFetcher.tryLoadChanges(VcsChangesSyncFetcher.java:54)
at jetbrains.buildServer.vcs.impl.VcsChangesLoaderImpl.tryLoadChanges(VcsChangesLoaderImpl.java:9)
at jetbrains.buildServer.serverSide.impl.VcsModificationChecker$CollectChangesAction$1.run(VcsModificationChecker.java:25)
at jetbrains.buildServer.util.NamedThreadFactory.executeWithNewThreadName(NamedThreadFactory.java:71)
at jetbrains.buildServer.serverSide.impl.VcsModificationChecker$CollectChangesAction.run(VcsModificationChecker.java:2)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: jetbrains.buildServer.vcs.VcsRootVcsException: VaultRepo {internal id=28}: Exception occurred while trying to connect to Vault server. See original message below:
null
at jetbrains.buildServer.buildTriggers.vcs.VcsRootChangesLoader$RunLoadChanges.run(VcsRootChangesLoader.java:54)
... 18 more
Caused by: jetbrains.buildServer.vcs.VcsException: VaultRepo {internal id=28}: Exception occurred while trying to connect to Vault server. See original message below:
null
at jetbrains.buildServer.buildTriggers.vcs.vault.impl.VaultConnectionImpl.login(VaultConnectionImpl.java:259)
at jetbrains.buildServer.buildTriggers.vcs.vault.impl.VaultConnectionImpl.login(VaultConnectionImpl.java:237)
at jetbrains.buildServer.buildTriggers.vcs.vault.connection.DelegatingVaultConnection.login(DelegatingVaultConnection.java:49)
at jetbrains.buildServer.buildTriggers.vcs.vault.connection.ExceptionAwareConnection.login(ExceptionAwareConnection.java:114)
at jetbrains.buildServer.buildTriggers.vcs.vault.connection.EternalVaultConnection.ensureActiveConnection(EternalVaultConnection.java:43)
at jetbrains.buildServer.buildTriggers.vcs.vault.connection.EternalVaultConnection.getFolderVersion(EternalVaultConnection.java:89)
at jetbrains.buildServer.buildTriggers.vcs.vault.connection.SynchronizedVaultConnection.getFolderVersion(SynchronizedVaultConnection.java:81)
at jetbrains.buildServer.buildTriggers.vcs.vault.VaultVcsSupport.getCurrentVersion(VaultVcsSupport.java:147)
at jetbrains.vcs.api.services.impl.RepositoryStateServiceProvider$1.getCurrentState(RepositoryStateServiceProvider.java:2)
at jetbrains.buildServer.vcs.impl.VcsRootInstanceImpl.getCurrentState(VcsRootInstanceImpl.java:189)
at jetbrains.buildServer.buildTriggers.vcs.VcsRootChangesLoader$RunLoadChanges.run(VcsRootChangesLoader.java:78)
... 18 more
Caused by: java.lang.NullPointerException
at clr.runtime.javautils.JavaObjectWrapper.toString(JavaObjectWrapper.java:22)
at clr.System.ObjectStaticWrapper.toString(Object.jvm.cs:89)
at VaultClientOperationsLib.RegistryKeys.GetDefaultAsString(Unknown Source)
at VaultClientOperationsLib.LocalSettings.GetString(Unknown Source)
at VaultClientOperationsLib.LocalSettings.GetString(Unknown Source)
at VaultClientOperationsLib.ClientInstance.get_LocalStoreBasePath(Unknown Source)
at VaultClientOperationsLib.ClientInstance.SetActiveRepositoryID(Unknown Source)
at VaultClientOperationsLib.ClientInstance.SetActiveRepositoryID(Unknown Source)
at VaultClientIntegrationLib.ServerOperations.SetRepository(ServerOperations.cs:4777)
at VaultClientIntegrationLib.ServerOperations.SetRepository(ServerOperations.cs:4748)
at VaultClientIntegrationLib.ServerOperations.Login(ServerOperations.cs:4678)
at VaultClientIntegrationLib.ServerOperations.Login(ServerOperations.cs:4796)
at jetbrains.buildServer.buildTriggers.vcs.vault.impl.VaultConnectionImpl.login(VaultConnectionImpl.java:249)
... 28 more
jetbrains.buildServer.vcs.VcsRootVcsException: VaultRepo {internal id=28}: Exception occurred while trying to connect to Vault server. See original message below:
null
at jetbrains.buildServer.buildTriggers.vcs.VcsRootChangesLoader$RunLoadChanges.run(VcsRootChangesLoader.java:54)
at jetbrains.buildServer.util.NamedThreadFactory.executeWithNewThreadName(NamedThreadFactory.java:71)
at jetbrains.buildServer.buildTriggers.vcs.VcsRootChangesLoader.loadChanges(VcsRootChangesLoader.java:32)
at jetbrains.buildServer.vcs.impl.VcsChangesFetcher$LoadChangesForRoot.run(VcsChangesFetcher.java:13)
at jetbrains.buildServer.vcs.impl.VcsChangesLoaderImpl$ImmediateFutureExecService$1.call(VcsChangesLoaderImpl.java:1)
at jetbrains.buildServer.serverSide.impl.ImmediateFuture.get(ImmediateFuture.java:59)
at jetbrains.buildServer.serverSide.impl.ImmediateFuture.get(ImmediateFuture.java:68)
at jetbrains.buildServer.vcs.impl.VcsChangesSyncFetcher.waitForTasksToComplete(VcsChangesSyncFetcher.java:125)
at jetbrains.buildServer.vcs.impl.VcsChangesSyncFetcher.doLoadChanges(VcsChangesSyncFetcher.java:28)
at jetbrains.buildServer.vcs.impl.VcsChangesSyncFetcher.tryLoadChanges(VcsChangesSyncFetcher.java:54)
at jetbrains.buildServer.vcs.impl.VcsChangesLoaderImpl.tryLoadChanges(VcsChangesLoaderImpl.java:9)
at jetbrains.buildServer.serverSide.impl.VcsModificationChecker$CollectChangesAction$1.run(VcsModificationChecker.java:25)
at jetbrains.buildServer.util.NamedThreadFactory.executeWithNewThreadName(NamedThreadFactory.java:71)
at jetbrains.buildServer.serverSide.impl.VcsModificationChecker$CollectChangesAction.run(VcsModificationChecker.java:2)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: jetbrains.buildServer.vcs.VcsException: VaultRepo {internal id=28}: Exception occurred while trying to connect to Vault server. See original message below:
null
at jetbrains.buildServer.buildTriggers.vcs.vault.impl.VaultConnectionImpl.login(VaultConnectionImpl.java:259)
at jetbrains.buildServer.buildTriggers.vcs.vault.impl.VaultConnectionImpl.login(VaultConnectionImpl.java:237)
at jetbrains.buildServer.buildTriggers.vcs.vault.connection.DelegatingVaultConnection.login(DelegatingVaultConnection.java:49)
at jetbrains.buildServer.buildTriggers.vcs.vault.connection.ExceptionAwareConnection.login(ExceptionAwareConnection.java:114)
at jetbrains.buildServer.buildTriggers.vcs.vault.connection.EternalVaultConnection.ensureActiveConnection(EternalVaultConnection.java:43)
at jetbrains.buildServer.buildTriggers.vcs.vault.connection.EternalVaultConnection.getFolderVersion(EternalVaultConnection.java:89)
at jetbrains.buildServer.buildTriggers.vcs.vault.connection.SynchronizedVaultConnection.getFolderVersion(SynchronizedVaultConnection.java:81)
at jetbrains.buildServer.buildTriggers.vcs.vault.VaultVcsSupport.getCurrentVersion(VaultVcsSupport.java:147)
at jetbrains.vcs.api.services.impl.RepositoryStateServiceProvider$1.getCurrentState(RepositoryStateServiceProvider.java:2)
at jetbrains.buildServer.vcs.impl.VcsRootInstanceImpl.getCurrentState(VcsRootInstanceImpl.java:189)
at jetbrains.buildServer.buildTriggers.vcs.VcsRootChangesLoader$RunLoadChanges.run(VcsRootChangesLoader.java:78)
... 18 more
Caused by: java.lang.NullPointerException
at clr.runtime.javautils.JavaObjectWrapper.toString(JavaObjectWrapper.java:22)
at clr.System.ObjectStaticWrapper.toString(Object.jvm.cs:89)
at VaultClientOperationsLib.RegistryKeys.GetDefaultAsString(Unknown Source)
at VaultClientOperationsLib.LocalSettings.GetString(Unknown Source)
at VaultClientOperationsLib.LocalSettings.GetString(Unknown Source)
at VaultClientOperationsLib.ClientInstance.get_LocalStoreBasePath(Unknown Source)
at VaultClientOperationsLib.ClientInstance.SetActiveRepositoryID(Unknown Source)
at VaultClientOperationsLib.ClientInstance.SetActiveRepositoryID(Unknown Source)
at VaultClientIntegrationLib.ServerOperations.SetRepository(ServerOperations.cs:4777)
at VaultClientIntegrationLib.ServerOperations.SetRepository(ServerOperations.cs:4748)
at VaultClientIntegrationLib.ServerOperations.Login(ServerOperations.cs:4678)
at VaultClientIntegrationLib.ServerOperations.Login(ServerOperations.cs:4796)
at jetbrains.buildServer.buildTriggers.vcs.vault.impl.VaultConnectionImpl.login(VaultConnectionImpl.java:249)
... 28 more
jetbrains.buildServer.vcs.VcsException: VaultRepo {internal id=28}: Exception occurred while trying to connect to Vault server. See original message below:
null
at jetbrains.buildServer.buildTriggers.vcs.vault.impl.VaultConnectionImpl.login(VaultConnectionImpl.java:259)
at jetbrains.buildServer.buildTriggers.vcs.vault.impl.VaultConnectionImpl.login(VaultConnectionImpl.java:237)
at jetbrains.buildServer.buildTriggers.vcs.vault.connection.DelegatingVaultConnection.login(DelegatingVaultConnection.java:49)
at jetbrains.buildServer.buildTriggers.vcs.vault.connection.ExceptionAwareConnection.login(ExceptionAwareConnection.java:114)
at jetbrains.buildServer.buildTriggers.vcs.vault.connection.EternalVaultConnection.ensureActiveConnection(EternalVaultConnection.java:43)
at jetbrains.buildServer.buildTriggers.vcs.vault.connection.EternalVaultConnection.getFolderVersion(EternalVaultConnection.java:89)
at jetbrains.buildServer.buildTriggers.vcs.vault.connection.SynchronizedVaultConnection.getFolderVersion(SynchronizedVaultConnection.java:81)
at jetbrains.buildServer.buildTriggers.vcs.vault.VaultVcsSupport.getCurrentVersion(VaultVcsSupport.java:147)
at jetbrains.vcs.api.services.impl.RepositoryStateServiceProvider$1.getCurrentState(RepositoryStateServiceProvider.java:2)
at jetbrains.buildServer.vcs.impl.VcsRootInstanceImpl.getCurrentState(VcsRootInstanceImpl.java:189)
at jetbrains.buildServer.buildTriggers.vcs.VcsRootChangesLoader$RunLoadChanges.run(VcsRootChangesLoader.java:78)
at jetbrains.buildServer.util.NamedThreadFactory.executeWithNewThreadName(NamedThreadFactory.java:71)
at jetbrains.buildServer.buildTriggers.vcs.VcsRootChangesLoader.loadChanges(VcsRootChangesLoader.java:32)
at jetbrains.buildServer.vcs.impl.VcsChangesFetcher$LoadChangesForRoot.run(VcsChangesFetcher.java:13)
at jetbrains.buildServer.vcs.impl.VcsChangesLoaderImpl$ImmediateFutureExecService$1.call(VcsChangesLoaderImpl.java:1)
at jetbrains.buildServer.serverSide.impl.ImmediateFuture.get(ImmediateFuture.java:59)
at jetbrains.buildServer.serverSide.impl.ImmediateFuture.get(ImmediateFuture.java:68)
at jetbrains.buildServer.vcs.impl.VcsChangesSyncFetcher.waitForTasksToComplete(VcsChangesSyncFetcher.java:125)
at jetbrains.buildServer.vcs.impl.VcsChangesSyncFetcher.doLoadChanges(VcsChangesSyncFetcher.java:28)
at jetbrains.buildServer.vcs.impl.VcsChangesSyncFetcher.tryLoadChanges(VcsChangesSyncFetcher.java:54)
at jetbrains.buildServer.vcs.impl.VcsChangesLoaderImpl.tryLoadChanges(VcsChangesLoaderImpl.java:9)
at jetbrains.buildServer.serverSide.impl.VcsModificationChecker$CollectChangesAction$1.run(VcsModificationChecker.java:25)
at jetbrains.buildServer.util.NamedThreadFactory.executeWithNewThreadName(NamedThreadFactory.java:71)
at jetbrains.buildServer.serverSide.impl.VcsModificationChecker$CollectChangesAction.run(VcsModificationChecker.java:2)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.NullPointerException
at clr.runtime.javautils.JavaObjectWrapper.toString(JavaObjectWrapper.java:22)
at clr.System.ObjectStaticWrapper.toString(Object.jvm.cs:89)
at VaultClientOperationsLib.RegistryKeys.GetDefaultAsString(Unknown Source)
at VaultClientOperationsLib.LocalSettings.GetString(Unknown Source)
at VaultClientOperationsLib.LocalSettings.GetString(Unknown Source)
at VaultClientOperationsLib.ClientInstance.get_LocalStoreBasePath(Unknown Source)
at VaultClientOperationsLib.ClientInstance.SetActiveRepositoryID(Unknown Source)
at VaultClientOperationsLib.ClientInstance.SetActiveRepositoryID(Unknown Source)
at VaultClientIntegrationLib.ServerOperations.SetRepository(ServerOperations.cs:4777)
at VaultClientIntegrationLib.ServerOperations.SetRepository(ServerOperations.cs:4748)
at VaultClientIntegrationLib.ServerOperations.Login(ServerOperations.cs:4678)
at VaultClientIntegrationLib.ServerOperations.Login(ServerOperations.cs:4796)
at jetbrains.buildServer.buildTriggers.vcs.vault.impl.VaultConnectionImpl.login(VaultConnectionImpl.java:249)
... 28 more
java.lang.NullPointerException
at clr.runtime.javautils.JavaObjectWrapper.toString(JavaObjectWrapper.java:22)
at clr.System.ObjectStaticWrapper.toString(Object.jvm.cs:89)
at VaultClientOperationsLib.RegistryKeys.GetDefaultAsString(Unknown Source)
at VaultClientOperationsLib.LocalSettings.GetString(Unknown Source)
at VaultClientOperationsLib.LocalSettings.GetString(Unknown Source)
at VaultClientOperationsLib.ClientInstance.get_LocalStoreBasePath(Unknown Source)
at VaultClientOperationsLib.ClientInstance.SetActiveRepositoryID(Unknown Source)
at VaultClientOperationsLib.ClientInstance.SetActiveRepositoryID(Unknown Source)
at VaultClientIntegrationLib.ServerOperations.SetRepository(ServerOperations.cs:4777)
at VaultClientIntegrationLib.ServerOperations.SetRepository(ServerOperations.cs:4748)
at VaultClientIntegrationLib.ServerOperations.Login(ServerOperations.cs:4678)
at VaultClientIntegrationLib.ServerOperations.Login(ServerOperations.cs:4796)
at jetbrains.buildServer.buildTriggers.vcs.vault.impl.VaultConnectionImpl.login(VaultConnectionImpl.java:249)
at jetbrains.buildServer.buildTriggers.vcs.vault.impl.VaultConnectionImpl.login(VaultConnectionImpl.java:237)
at jetbrains.buildServer.buildTriggers.vcs.vault.connection.DelegatingVaultConnection.login(DelegatingVaultConnection.java:49)
at jetbrains.buildServer.buildTriggers.vcs.vault.connection.ExceptionAwareConnection.login(ExceptionAwareConnection.java:114)
at jetbrains.buildServer.buildTriggers.vcs.vault.connection.EternalVaultConnection.ensureActiveConnection(EternalVaultConnection.java:43)
at jetbrains.buildServer.buildTriggers.vcs.vault.connection.EternalVaultConnection.getFolderVersion(EternalVaultConnection.java:89)
at jetbrains.buildServer.buildTriggers.vcs.vault.connection.SynchronizedVaultConnection.getFolderVersion(SynchronizedVaultConnection.java:81)
at jetbrains.buildServer.buildTriggers.vcs.vault.VaultVcsSupport.getCurrentVersion(VaultVcsSupport.java:147)
at jetbrains.vcs.api.services.impl.RepositoryStateServiceProvider$1.getCurrentState(RepositoryStateServiceProvider.java:2)
at jetbrains.buildServer.vcs.impl.VcsRootInstanceImpl.getCurrentState(VcsRootInstanceImpl.java:189)
at jetbrains.buildServer.buildTriggers.vcs.VcsRootChangesLoader$RunLoadChanges.run(VcsRootChangesLoader.java:78)
at jetbrains.buildServer.util.NamedThreadFactory.executeWithNewThreadName(NamedThreadFactory.java:71)
at jetbrains.buildServer.buildTriggers.vcs.VcsRootChangesLoader.loadChanges(VcsRootChangesLoader.java:32)
at jetbrains.buildServer.vcs.impl.VcsChangesFetcher$LoadChangesForRoot.run(VcsChangesFetcher.java:13)
at jetbrains.buildServer.vcs.impl.VcsChangesLoaderImpl$ImmediateFutureExecService$1.call(VcsChangesLoaderImpl.java:1)
at jetbrains.buildServer.serverSide.impl.ImmediateFuture.get(ImmediateFuture.java:59)
at jetbrains.buildServer.serverSide.impl.ImmediateFuture.get(ImmediateFuture.java:68)
at jetbrains.buildServer.vcs.impl.VcsChangesSyncFetcher.waitForTasksToComplete(VcsChangesSyncFetcher.java:125)
at jetbrains.buildServer.vcs.impl.VcsChangesSyncFetcher.doLoadChanges(VcsChangesSyncFetcher.java:28)
at jetbrains.buildServer.vcs.impl.VcsChangesSyncFetcher.tryLoadChanges(VcsChangesSyncFetcher.java:54)
at jetbrains.buildServer.vcs.impl.VcsChangesLoaderImpl.tryLoadChanges(VcsChangesLoaderImpl.java:9)
at jetbrains.buildServer.serverSide.impl.VcsModificationChecker$CollectChangesAction$1.run(VcsModificationChecker.java:25)
at jetbrains.buildServer.util.NamedThreadFactory.executeWithNewThreadName(NamedThreadFactory.java:71)
at jetbrains.buildServer.serverSide.impl.VcsModificationChecker$CollectChangesAction.run(VcsModificationChecker.java:2)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Re: TeamCity 2017.1.2 & Vault 10
Ok, I've made a discovery. Not sure how it helps, but hopefully it can help narrow things down.
I have TC running under a domain user account which I created specifically to run TeamCity. The Vault app pools actually use this same account (but Vault is on a separate server from TC).
I changed the TeamCity windows service to run under my domain user account. I also deleted all the files in the build users local temp folder (in Local), and I also saw a Vault/Client folder in the profile folder as well which had an XML settings file. I deleted that. I restarted the server (now running on my account) and tested the connection, and it worked. I put it back to the build domain user account, and it continues to work.
So it looks like some temp file, or maybe the vault client settings file was causing some kind of issue.
Sorry to take up so much of your time on this, it never occurred to me something in the user's profile data could cause such an issue.
I have TC running under a domain user account which I created specifically to run TeamCity. The Vault app pools actually use this same account (but Vault is on a separate server from TC).
I changed the TeamCity windows service to run under my domain user account. I also deleted all the files in the build users local temp folder (in Local), and I also saw a Vault/Client folder in the profile folder as well which had an XML settings file. I deleted that. I restarted the server (now running on my account) and tested the connection, and it worked. I put it back to the build domain user account, and it continues to work.
So it looks like some temp file, or maybe the vault client settings file was causing some kind of issue.
Sorry to take up so much of your time on this, it never occurred to me something in the user's profile data could cause such an issue.
Re: TeamCity 2017.1.2 & Vault 10
Wow! I was trying to figure out what was different in the configurations. The TeamCity setup we had were configured with default values. So, yes, it appears something in the client cache or in the settings.xml file was interfering with the connection.
FWIW, in .NET land, Vault will use the registry for storage of its client side settings. However, in the Java transpiled world, the libraries actually store stuff in the settings.xml file. Sorry it never dawned on me to ask you to try another user which would have created a different settings.xml file.
Regardless, I'm glad you were able to track this down, and hopefully this thread will help anyone else that runs into this odd situation.
FWIW, in .NET land, Vault will use the registry for storage of its client side settings. However, in the Java transpiled world, the libraries actually store stuff in the settings.xml file. Sorry it never dawned on me to ask you to try another user which would have created a different settings.xml file.
Regardless, I'm glad you were able to track this down, and hopefully this thread will help anyone else that runs into this odd situation.
Jeff Clausius
SourceGear
SourceGear