-
Notifications
You must be signed in to change notification settings - Fork 407
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
Environment variables are not cleaned up #263
Comments
I believe |
Ah... Maybe my repro steps are not perfectly describing the issue. But I can confirm that the web app we're running is getting those environment variables as well. They're critical to the app, and they're marked as mandatory using a Figaro initializer (which means the app wouldn't even start if they weren't defined). |
Well, I'd be open to a PR to document additional ways to set env vars. |
I'm not quite sure I understand how this is an additional way to set an env var. The variable is set up in the container's environment (using docker-compose, but under the hood, it's the same thing as using I'm totally fine with it, as long as this is not a bug which will be fixed in a future version and may break apps very unexpectedly. |
Hey there! 👋
We're using this image (
phusion/passenger-ruby25:1.0.5
) to run a Rails app, and we are not seeing the behavior documented at https://github.com/phusion/passenger-docker#setting-environment-variables-in-nginx. Environment variables that are set up through Docker Compose .env mechanism are visible to the Rails app.My question is:
My biggest concern is that this is fixed inadvertently in a further version, and apps suddenly start breaking for obscure reasons when updating the Phusion Passenger image version.
Reproduction steps
We are using docker-compose. Here are relevant extracts and reproduction steps:
# .env TEST_ENV_VAR=test1234
env.conf
does not contain any line likeenv TEST_ENV_VAR;
, yet the following is possible:The text was updated successfully, but these errors were encountered: