Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: environment variables (e.g. for proxy support) #547

Open
Obirah opened this issue Feb 9, 2023 · 3 comments
Open

Feature Request: environment variables (e.g. for proxy support) #547

Obirah opened this issue Feb 9, 2023 · 3 comments

Comments

@Obirah
Copy link

Obirah commented Feb 9, 2023

As an enterprise user that is working behind an internet proxy, I would like to be able to pass environment variables that are used during the initialization of the runner to the constructs so that I can correctly configure the proxy URL and no-proxy list.

@pflorek
Copy link
Member

pflorek commented Feb 10, 2023

Hey @Obirah ,

actually you can pass env vars to the runner:

https://github.com/pepperize/cdk-autoscaling-gitlab-runner/blob/main/API.md#environmentoptional-

Which configuration properties are missing exactly to you https://docs.gitlab.com/runner/configuration/advanced-configuration.html ?

You may open a PR adding them.

Regards,
Patrick

@Obirah
Copy link
Author

Obirah commented Feb 10, 2023

Hey Patrick,

thank you for the quick response! I'm using the environment property to pass my proxy environment to runner, however I don't think that this is sufficient for my setup:

I need the proxy to be in effect here so that this call to packages.gitlab.com goes through the proxy.

Optionally, it would also be alright to be able to replace https://packages.gitlab.com with our internal GitLab RPM mirror, however I don't think this is really feasible as https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh will also point to the original URL and not the mirror.

@pflorek
Copy link
Member

pflorek commented Feb 11, 2023

Hey @Obirah ,

you may refactor the init config step repositories to be passed by the construct's props. Then you pass your own InitConfig to setup your private mirror.
The step packages may also bei refactored to pass your own docker+machine gitlab fork binary.
I guess, you also want to provide a hardened or customized AMI for the manager instance.

That combination could give you the desired flexibility.

I considered CDK escape hatches with InitConfig won't work very well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants