Expose runner environment variables to gitlab-runner installation scripts

[UiP9AV6Y]

As part of the VM provisioning, the tart-executor installs gitlab-runner as it is one the of prerequisits for the build environment. tart-executor supports two strategies; downloading via curl or brew

We use an internal homebrew cache in order to speed up the usage of brew as part of our CI environment. For this to work, we define HOMEBREW_ARTIFACT_DOMAIN and HOMEBREW_DOCKER_REGISTRY_TOKEN as executor environment variables. These variables are available throughout every custom executor stage but are not forwarded to any logic happening inside the VM; only the build stage receives them as gitlab-runner exposes them as part of the build script via a series of export statements.

In order for the gitlab-runner installation as part of the preparation phase to benefit from our internal cache, i would like to see the environment variables also forwarded to the installation script.

Another usecase could be the use of HTTP proxies. Assuming a build environment has restricted access to the internet, both the curl as well as brew installation would fail. In this case the runner would be provisioned with HTTP_PROXY variables which would also be needed during the gitlab-runner installation step.

The environment variables are already processed as part of the gitlab.InitEnv() function, but most of the values are discarded.

ssh#Session.Setenv

setting the environment using Setenv for the installation script session would solve the issue

pro: the installation scripts must not be changed
contra: sshd might be configured to reject or/some environment variables

export

injecting the environment variables into the installation scripts would closely resemble the logic gitlab-runner does for the build stage.

pro: the sshd configuration has no impact on the functionality
contra: -

[UiP9AV6Y]

if this feature request is accepted, i can come up with a PR implementing the changes

[edigaryev]

I think export is the way to go, since Setenv() requires additional configuration on the SSH server's side. In fact, we already do this in Cirrus CLI.

Do you want to re-export all variables starting with CUSTOM_ENV_ to the SSH session, stripping the prefix?

[UiP9AV6Y]

Do you want to re-export all variables starting with CUSTOM_ENV_ to the SSH session, stripping the prefix?

essentially, yes

[edigaryev]

Do you want to re-export all variables starting with CUSTOM_ENV_ to the SSH session, stripping the prefix?

essentially, yes

SGTM.

/cc @fkorotkov

[fkorotkov]

SGTM too