Hi there, I’ve run into an issue where I’m installing a program that needs a few environment variables set to function and I am not sure how to have these variables persisted to the build job.
We run AWS EC2s for our build machines. We set some variables in the AMI build and some in the cloud init user data script. I would like to just append variables to /etc/environment and have those be available in the job.
What I’m seeing is that the job runs without any of these variables, it seems to have a very minimal environment in addition to the various BUILDKITE_* vars. If I ssh into the box, switch user to buildkite-agent, and check the env, the variables are all set correctly and available.
Is this expected behavior? If so, how should I be injecting system-level environment variables into the job?
This documentation leads me to believe that the agent’s environment should contain " operating system environment variables" and merge them with the job environment to get the job runtime environment. Am I reading this wrong? What exactly does “operating system env vars” mean if not /etc/environment?
I should also note that on our Windows boxes, setting system-level environment vars (and restarting the buildkite agent service if it’s running) works as I’d expect, the jobs have access to those variables.
After more investigation we found that the default buildkite-agent.service doesn’t pull in any environment and that we would have to inject our needed environment somehow. It took some deep diving into how systemd starts up services to realize this though. We opted for using the environment hook which sources /etc/environment which is acceptable for our purposes. We also considered adding an EnvironmentFile= to the service but opted for the additive change.
I think the documentation I linked previously is misleading and would be great if it were updated to mention that the default service on linux does not propagate any environment vars, maybe with a link to systemd documentation.
Looks like you were able to find an answer to your question, and that’s an excellent find! I agree that our documentation should make a mention of that caveat somewhere, I’ll make sure that we get it updated.
