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

Defaulting to ENV vars during container build is problematic #66

Open
Richtermeister opened this issue Feb 2, 2018 · 1 comment
Open
Labels
needs discussion Requires internal analysis/discussion

Comments

@Richtermeister
Copy link

First off, this bundle has come a long way and I really like it now, great job, and thank you!

One snag I ran into though:

Expected behavior

According to the documentation I can configure this bundle via ENV vars, specifically, setting BUGSNAG_API_KEY – the idea of ENV vars being that I can change their values during deploy time to produce different runtime behavior.

Observed behavior

However, by default ENV vars only end up as a default-values to the container build step, and are consequently frozen into the container as resolved value. A change to ENV vars will not affect a change to the runtime configuration, without rebuilding the container. See: https://github.com/bugsnag/bugsnag-symfony/blob/master/DependencyInjection/Configuration.php#L26

Steps to reproduce

  1. Warm the cache (build container) while providing BUGSNAG_API_KEY via ENV var.
  2. Start a webserver hosting the bundle with a different ENV setting.
  3. Trigger error report & observe it going to the build-time account. Alternatively, look into the cached container and find frozen resolved value.

Version

1.5.0

Additional information

By explicitly specifying the api_key via ENV var, the bundle remains configurable at runtime:

bugsnag:
    api_key: "%env(BUGSNAG_API_KEY)%"

My recommendation would be to avoid setting default values via ENV inside the Configuration class and instead require them to be specified inside the bugsnag.yml config file.

@Cawllec
Copy link
Contributor

Cawllec commented Feb 2, 2018

I think this is fair, if environment variables are expected to configure options that should be respected in all environments. What do you think @GrahamCampbell?

@abigailbramble abigailbramble added the needs discussion Requires internal analysis/discussion label Oct 3, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs discussion Requires internal analysis/discussion
Projects
None yet
Development

No branches or pull requests

3 participants