TeamCity 2017.1.2 & Vault 10

[ajj3085]

Seems like every Vault update breaks TeamCity integration. I've filed an issue with JetBrains, I have updated the Vault plugin with the 10 java library already. I'd appreciate if SourceGear could take a look at tis too.

Thanks

https://youtrack.jetbrains.com/issue/TW-50406

[Beth]

Is the Vault client working and connecting to the Vault server?

Did you put in updated Vault Jar files?

On the TeamCity website the instructions say "Put the Vault Java API jars (available with Java Command Line client) into the <TeamCity Data Directory>/plugins/VaultAPI/lib folder." With each Vault update, you have to put in the jar files that correspond to the Vault version you are using. For example, any method of connecting from Vault 9 cannot connect to a Vault 10 server. If it appears to break every upgrade then that is the likely culprit.

[ajj3085]

Is the Vault client working and connecting to the Vault server?

Did you put in updated Vault Jar files?

On the TeamCity website the instructions say "Put the Vault Java API jars (available with Java Command Line client) into the <TeamCity Data Directory>/plugins/VaultAPI/lib folder." With each Vault update, you have to put in the jar files that correspond to the Vault version you are using. For example, any method of connecting from Vault 9 cannot connect to a Vault 10 server. If it appears to break every upgrade then that is the likely culprit.

Hi Beth, yes as I've said I update the updated Vault jar viles in the TCD/plugins/VaultAPI/lib folder. I've verified that I can use the Java CLC from the TeamCity server (using the libs in the plugin folder) to connect.

Referring back to this thread: viewtopic.php?f=5&t=22709

IIRC, the Vault 9.1 release is what initially caused this issue. I believe I was told to try the 9.0 Java CLC libraries to see if that would work, and it did. Of course, that's not an option anymore. I think the issue may have started in Vault 9.1 and just has never been fixed.

[jclausius]

I'm not an expert on TeamCity by any means, but one of the JetBrains' devs asked us to ask :

the user to set the following internal property: teamcity.vcs.vault.classloading=full and restart the server?

Any changes?

[ajj3085]

I'm not an expert on TeamCity by any means, but one of the JetBrains' devs asked us to ask :

the user to set the following internal property: teamcity.vcs.vault.classloading=full and restart the server?

Any changes?

I'm not sure where to do that.

[jclausius]

I'll ask.

While we're waiting, is there a .properties file or .props file that TeamCity uses? Perhaps you can find something in there or search thru the TeamCity files for a mention of Vault? It might be something that you come across in a search.

[ajj3085]

I'll ask.

While we're waiting, is there a .properties file or .props file that TeamCity uses? Perhaps you can find something in there or search thru the TeamCity files for a mention of Vault? It might be something that you come across in a search.

Thanks. There are a lot of .properites files scattered about the team city installation and data locations. I'll see if I can find one that looks like it might be the right one.

[jclausius]

OK. I have not heard back from JetBrains.

[jclausius]

OK, I've been instructed to ask you to try this link: https://confluence.jetbrains.com/displa ... properties

[ajj3085]

OK, I've been instructed to ask you to try this link: https://confluence.jetbrains.com/displa ... properties

Sorry it took a while to get back to this. I tried setting that property and it had no effect.

[jclausius]

I apologize. I missed your followup post.

We've set up TeamCity 2017.1.3 server in house on a Windows 2012 R2 Server with Vault 10 Java API libraries in the .../plugins/VaultAPI/lib/.


Within TeamCity, went to -> Administration -> Global Settings. Located the TeamCity Data directory. Next from explorer, opened up that location on disk, and created a sub folder named "VaultAPI". Finally, downloaded the Vault 10 JavaCLC client, unzipped it, and copied the lib/ directory from inside the zip into the VaultAPI\ on disk. So, on our end the resulting copied files looked like "C:\ProgramData\JetBrains\TeamCity\plugins\VaultAPI\lib" where lib\ contains the Vault *.jar files.

Next entered the Vault server URL - http://vaultprodemo.sourcegear.com/VaultService for this test (using Vault Professional's Java CLC), typed in "Initial Repository", and enter the 'guest' credential information. Next, clicked the 'Test connection' button which brought up the 'Test Connection : Connection successful!' dialog.

Does this setup mirror your configuration?

[ajj3085]

I apologize. I missed your followup post.

We've set up TeamCity 2017.1.3 server in house on a Windows 2012 Server with Vault 10 Java API libraries in the .../plugins/VaultAPI/lib/.


Within TeamCity, went to -> Administration -> Global Settings. Located the TeamCity Data directory. Next from explorer, opened up that location on disk, and created a sub folder named "VaultAPI". Finally, downloaded the Vault 10 JavaCLC client, unzipped it, and copied the lib/ directory from inside the zip into the VaultAPI\ on disk. So, on our end the resulting copied files looked like "C:\ProgramData\JetBrains\TeamCity\plugins\VaultAPI\lib" where lib\ contains the Vault *.jar files.

Next entered the Vault server URL - http://vaultprodemo.sourcegear.com/VaultService, typed in "Initial Repository", and enter the 'guest' credential information. Next, clicked the 'Test connection' button which brought up the 'Test Connection : Connection successful!' dialog.

Does this setup mirror your configuration?

Its pretty close, but some differences; my TeamCity (2017.1.2) is running on Server 2012 R2. I have the Vault CLC in C:\TeamCityData\plugins\VaultAPI\lib as that was the directory TC has been using since I first set it up (maybe on version 9?). Also, both my TC and Vault are running under HTTPS, and TC is running on 64-bit Java 1.8.0_131. Not sure if any of that could explain anything. Also not sure if it matters, but my TeamCity database is running on Sql Server connected via JDBC.

[jclausius]

Sorry, our test server was running Windows 2012 Server R2. I've corrected my post.

Also, to clarify, in this test we used the Vault Standard version 10 of the the Java CLC. The Vault Standard "Client API" version 10 will not work, nor will the Vault Professional version 10 of the Java CLC. If either of those are configured or a different version (for example, Vault 8 or Vault 9), you will either receive a configuration error or an incorrect protocol error.

We've upgraded TeamCity's JRE to 64-bit, and after setting the TEAMCITY_SERVER_MEM_OPTS to allow a larger memory limit, can connect to https://vaultdemo.sourcegear.com/VaultService this time testing the Vault Standard 10 Java CLC.

To verify, your C:\TeamCityData\plugins\VaultAPI\lib directory has a bunch of related *.jar files, correct? I would think it would have to to even get anywhere in your setup.

Also note, we had to use the fully qualified domain name (http://vaultdemo.sourcegear.com/VaultService and http://vaultprodemo.sourcegear.com/VaultService). Using the host's name (http://vaultdemo/VaultService) would not work.

Finally, since you're using HTTPS, I wonder if you're having problems related to the keystore or the URL not matching the machine's name on the SSL Cert. I don't know how this configuration works within the Java runtime for TeamCity, but posting these links just in case:

+ viewtopic.php?t=10526
+ viewtopic.php?f=5&t=15336
+ viewtopic.php?f=51&t=22622

[ajj3085]

Sorry, our test server was running Windows 2012 Server R2. I've corrected my post.

Also, to clarify, we used the Vault Standard version 10 of the the Java CLC. The Vault Standard "Client API" version 10 will not work, nor will the Vault Professional version 10 of the Java CLC. If either of those are configured or a different version (for example, Vault 8 or Vault 9), you will either receive a configuration error or an incorrect protocol error.

I have the correct Java CLC. I've seen the protocol error in TC before, but that's not what I'm getting.

We've upgraded TeamCity's JRE to 64-bit, and after setting the TEAMCITY_SERVER_MEM_OPTS to allow a larger memory limit, can connect to https://vaultdemo.sourcegear.com/VaultService this time testing the Vault Standard 10 Java CLC.

Were you getting errors previous to setting TEAMCITY_SERVER_MEM_OPTS? I don't have that set.

To verify, your C:\TeamCityData\plugins\VaultAPI\lib directory has a bunch of related *.jar files, correct? I would think it would have to to even get anywhere in your setup.

Yes, the lib contains the JAR files. I'm able to use the CLC from the command line from the lib folder, and that seems to work.

Also note, we had to use the fully qualified domain name (http://vaultdemo.sourcegear.com/VaultService and http://vaultprodemo.sourcegear.com/VaultService). Using the host's name (http://vaultdemo/VaultService) would not work.

Also using a FQDN.

Finally, since you're using HTTPS, I wonder if you're having problems related to the keystore or the URL not matching the machine's name on the SSL Cert. I don't know how this configuration works within the Java runtime for TeamCity, but posting these links just in case:

+ viewtopic.php?t=10526
+ viewtopic.php?f=5&t=15336
+ viewtopic.php?f=51&t=22622

I can check those threads, but the cert is one purchased from GoDaddy, and using a browser from the server to login to Vault works with no certificate warnings.

This issue originally started for me on Vault 9, after a point release. The resolution then was to use an older version of the Vault 9 Java CLC, and that fixed it. viewtopic.php?f=5&t=22709 It was in an email that suggested going back to the 9.0 CLC instead of using the 9.1 update.

One other thing I thought of which I'm not sure makes a difference is that I'm using Checkout rules. So if I have two build configurations they both share a VCS root to the same Vault repo, and the checkout rules are used to determine trunk or a branch.

For example my trunk build configuration has:

Code: Select all

-:.
+:/MyProject1/trunk => .

And my branch

Code: Select all

-:.
+:/MyProject1/2.6.0 => .

Maybe those are tripping things up? I'd be a bit surprised though as the CO rules are at the build configuration level, and the VCS root is at the <Root project> level.

[ajj3085]

I tried creating another VCS root to another Vault repository, and that doesn't work for me either. So I guess checkout rules aren't the issue.