Cannot set per-cloud environment variables

[dkfitbit]

Our GCE cloud is configured to not allow direct Internet access, either via external IP or via NAT, and all traffic must leave via a proxy where it can be logged. However, the GCE plugin does not provide any way to set the required http_proxy et al environment variables on a per-cloud basis; the best available workaround would be to set them at the Jenkins global level, but then our non-GCE instances (bare metal, legacy EC2, corp Mac Minis, etc) will have the wrong proxy configured.

[stephenashank]

Hi @dkfitbit , I have been looking into this and I'd like to clarify what contexts you need these environment variables set for. I've attempted ways to set these variables through the startup script but have not had any luck so far.

[dkfitbit]

Example:

export http_proxy="http://some.proxy:3128"
export https_proxy="http://some.proxy:3128"
export no_proxy="localhost,.internal,169.254.169.254"
# usual Jenkins start-up
java -jar slave.jar
# now all subprocesses started on this executor by Jenkins have $http_proxy set

There might be other adequate ways to make those variables propagate to (1) all jobs that run on the executor (2) but no other executors, but the most obvious way is to set them when launching the JNLP slave.jar, which is what the EC2 plugin does.

[dkfitbit]

It might help to know that we have a mix of executor types: cloud VMs that Jenkins deploys, bare metal machines that Jenkins SSHes into, and Mac Minis that live in corp and that connect to Jenkins (because Jenkins cannot reach them through the firewall). Each of these different machine types needs different environment variables set. One Jenkins job might use multiple machine types, perhaps even in parallel, and the environment variable values for a given machine type are the same for hundreds of jobs.

TL;DR: this is a major pain point compared to the EC2 plugin, which simply lets us customize the slave jar command line.

[stephenashank]

Thanks, that's actually extremely helpful. I would need to consult with our team on completely opening up customization of the launch command in that way. I don't believe it was intended to be used in this way, but it is actually now possible with the javaExecPath field (once release 3.2.0 hits the update center).

While we work on a more robust solution, here is the workaround that was just enabled. Configure the javaExecPath field something like this:

export http_proxy="http://some.proxy:3128";export https_proxy="https://some.proxy:3128";export no_proxy="localhost,.internal,169.254.169.254";java

It will work as long as the last part of the string is java or whatever the appropriate java executable path is.

[rachely3n]

Any updates? @dkfitbit

[dkfitbit]

We haven't had time to upgrade from 1.0.5 (we're several months behind on our patching for all plugins, not just GCE).