Adding a config setting should never be dangerous (if it is your system is deeply broken) and should be distinct from changing an existing config setting.
> Adding a config setting should never be dangerous (if it is your system is deeply broken)
While I can't name anything specific offhand, I feel pretty strongly that I've seen documentation for various things stating that those things check for an environment variable and, if it isn't present, fall back to other candidate names for the same variable.
This makes setting a new variable synonymous with changing an existing one, unless all variables are currently using the highest-priority possible names.
Another architecture with the same effect is that the software will only check a single environment variable, and if not present it will use a default value. That also makes setting a new variable synonymous with changing an existing one.
You've never seen software that will use a default value, instead of refusing to operate, when a particular environment variable isn't present in the environment?
I was deploying some dotnet app and it broke because the devs baked a config key into the image that was otherwise unset, which enabled it trying to start a SSL endpoint without a cert, thus breaking the app.
Are you talking about altering environment variables in a system, or altering software to read different environment variables? I read jt2190 as talking about the former.
I don’t use env variables for this and many other reasons. They seem like a spectacularly bad idea for config, as the op noted.
I’m talking about altering a config which you control - adding to a config is pretty risk free if it is your program, altering a config of course is not.
