support .env file to load env #2675
Conversation
|
Can you update the advanced configuration section of the readme and add a unit or integration test* for the functionality? |
| @@ -22,6 +22,7 @@ import ( | |||
| "log" | |||
| "os" | |||
|
|
|||
| _ "github.com/joho/godotenv/autoload" | |||
There was a problem hiding this comment.
What is the behavior of invalid .env content and would it be better to use the library directly to marshal the error to a proper handler, like in main or internal/settings?
There was a problem hiding this comment.
What behavior would you like to see if the content is invalid? Should the collector forcefully exit then, or is an error log ok?
There was a problem hiding this comment.
imo I'd expect there to be a logged warning about the validity of the file w/ the parsing error and for none of the env vars in the file to be sourced but can see other options being desirable. I'm not sure how feasible this is given we aren't controlling the implementation as is*. Terminating the collector seems overkill.
There was a problem hiding this comment.
thanks, I'll factor that in.
+1 to this, and specifically it'd be nice to have an invocation example in the |
|
Upstream is talking about going with different binaries as an option: open-telemetry/opentelemetry-collector#7350 |
Fixes #2643
This adds an autoload of any .env file located in the working directory when invoking the collector.
A .env file may contain environment variables that then get loaded as part of the env vars seen by the collector.
This is a lightweight approach to fixing the issue.