fix: GetModuleContext: use config from context instead of from envar #1534
Conversation
…stead of creating a new managers using the envar file
safeer
force-pushed
the
controller-getmodulecontext-use-ctx
branch
from
3de44bd
to
339dddf
Compare
|
For your fourth case:
Have we discussed whether that should instead merge the contents of Great job knocking this out in any case! |
|
Thanks @deniseli! I had a conversation with @wesbillman and @worstell, and we all agreed that having the CLI path override the envar makes the most sense, since it's more explicit. I'll hold off until we can talk about it during the sync :) |
There was a problem hiding this comment.
Sweet, thanks @safeer! That makes complete sense. I'll go ahead and approve so you aren't blocked on merging. If y'all already talked through it, then it sounds like this is ready to go :)
The only remaining thought I had was whether it'd be useful to log some sort of warning if we happen to override the envar with the flag, in case someone's using the flag without realizing there's also an envar config. That's low enough impact, though, that even if we did want to do that, you are more than welcome to do that in a followup :)
|
Looks like the override actually happens separately in Kong :) |
Fixes #1352
With this change, the behavior is:
ftl dev examples/goftl-project.tomlin the gitroot if it existsFTL_CONFIG=ftl-project-inline-a.toml ftl dev examples/goftl-project-inline-a.tomlftl dev examples/go --config=ftl-project-inline-b.tomlftl-project-inline-b.tomlFTL_CONFIG=ftl-project-inline-a.toml ftl dev examples/go --recreate --config=ftl-project-inline-b.tomlftl-project-inline-b.toml