Teamcity 2017.1.2. set http.proxy per VCS Root

I narrowed it down to what I really were after:

I managed to setup proxy for Teamcity via _JAVA_OPTIONS, so it looks like something like this

-Dhttp.proxyHost=<proxyserver>
-Dhttp.proxyPort=<port>
-Dhttp.nonProxyHosts="localhost|127.0.0.1|<host1>|<host2>|etc"
-Dhttps.proxyHost=<proxyserver>
-Dhttps.proxyPort=<port>
-Dhttps.nonProxyHosts="localhost|127.0.0.1|<host1>|<host2>|etc"

With this setup you can get projects from GitHub, however Git will not be able to pull projects from the outside since it's only teamcity that has set the proxy.

What is additionally necessary is to set the proxy in the git bash through a build step:

""C:\Program Files\Git\bin\git.exe" config --global http.proxy  <proxyUrl>:<proxyPort>"

After the project has been pulled, the following command has to run

""C:\Program Files\Git\bin\git.exe" config --global --unset http.proxy"

My problem is if the build fails, the build step which unsets the proxy is never run. 

What would be desirable to have in the VCS root settings, is some parameter fields that is run before and after a pull.

So each time a pull is triggered, the proxy is set and then unset after the pull is completed. 

Otherwise the server will not have access to local git repositories after the pull is completed but the build has failed.

The quick solution to getting a build through, at least for my buildserver:

After adding the Github project to Teamcity, go to the build configuration, Version Control Settings and change the VCS checkout mode to "Always checkout files on server"

Hi Harald,

First of all, why do you need to unset the proxy? Wouldn't it make sense to keep the proxy configuration added to that git client if it is going to regularly have to connect to the server?

Then, if you really need to do it, you can configure the build step to run even if the previous step failed.

We have a request in our issue tracker for adding authentication support for this type of situations, but it's a complex issue. Please feel free to watch, vote and add any comments here: https://youtrack.jetbrains.com/issue/TW-12443

Sadly we have to unset the proxy for git otherwise internal repositories will be unavailable, the proxy is fairly strict in our corporate environment. 

I also noticed another scenario where I'll need to add the proxy settings:

When I'm creating a new project and choosing to use the "From a repository URL" option to get an external repository, Teamcity will also need to have the proxy settings available in a different manner unlike the "From Github.com" option.

I've looked up https://confluence.jetbrains.com/display/TCD10/Creating+and+Editing+Projects#CreatingandEditingProjects-CreatingProjectfromURL to figure out the difference, but I'm not sure how to go about it.

I just end up with a message like this in the teamcity-vsc.log:

[2017-07-06 10:23:04,184]   WARN [-nio-80-exec-72] - Triggers.vcs.git.GitVcsSupport - List remote refs failed: git@github.com:angelovstanton/Projects.git: Connection timed out: connect, 2 attempt(s) left 

Hi Harald,

When using "From Github.com" it uses the Github.com integration feature, while connecting through a repository url will not use that connection feature, but that's the extent of the differences. They should end up using the same connection, which should be the server's configuration. The feature should only help with authentication, so they shouldn't need different configurations for the proxy.

Harald case is a real-life problem experienced by a lot of users in the corporate world. (including me and my firm, and we have quite a decent number of purchased licenses)

My TC farm connects to github, internal sites, other external repos... Each URL requires in some cases a different proxy configuration. And that's not by choice, there are legal requirements..
Sorry, that's the corporate world, the one that pays for commercial licenses rather than moving to Jenkins. Given that at least in a git-based environment it is entirely possible to establish proxy (as well as sslVerify settings) settings  per URL, I fail to see why it is that hard to implement, and why it hasn't happened yet. 

The ticket you mentioned earlier , https://youtrack.jetbrains.com/issue/TW-12443, hasn't seen any Jetbrains official updates in over a year. Quite disappointing really. Furthermore, It was created 7 years ago...

This issue is LITERALLY the dealbreaker in us staying on Teamcity at this point. 

I was reading the release notes for 2017.2  : https://confluence.jetbrains.com/display/TW/TeamCity+2017.2+Release+Notes

As usual with the new versions, tons of new features, tons of time spent on docker, kotlin, nuget... All the startups using TC for free must be really, really happy with the improvements.
I could be running in TC 7, provided I had proper proxy support for VCS roots...

Hello Juan,

As a workaround is it possible to setup the proxy the way that it will use the different settings for different URLs?

Afraid not.  Companies with > 25k employees tend to have tight controls on how proxies are configured.
This is standard practice...

But again (and yes, apples and oranges, I get it)... https://github.com/jenkinsci/git-client-plugin/pull/201

I mean you can set up a proxy that will be used by the TeamCity server only, and which will route the requests to the other proxies based on URL. Is that possible?

In this case, this proxy server can be considered as a part of TeamCity installation. I know that this looks like a workaround while the source issue is not fixed yet.

Setting up a proxy would imply I have physical access, with the proper admin rights, to the TC server box.

Also, I am pretty sure security would escort me out of my building if the IT security department finds out I am setting proxies, even for well intended purposes.

I know for most people it sounds weird, but financial firms, federal institutions, some research labs, law firms, etc have some very strict rules about what gets installed, how it is used, and where/how you go get data.

And all this topic implies using server-side checkout. Don't get me started on using agent-checkout.... (assume a teamcity farm with agents in 5 to 10 different locations, in different countries/continents, with different proxies.

My interim solution (meaning, what we have been doing for 4 years) is to checkout using my own scripts and bypassing the git plugin, controlling proxies via agent-side environment variables... but obviously that limits the amount of things we can do with teamcity tremendously.

Hi, Juan.

Thanks for the feedback. Could you please describe your case in the comments for https://youtrack.jetbrains.com/issue/TW-12443 ?

I mean which parts of TeamCity should use configurable proxy settings? TeamCity consists of a number of plugins, so it's not so easy to implement a general solution which will cover all the outgoing requests, but maybe it will be easier to fix it for some particular requests.