Fix binding configuration file settings to command flags #2738
Conversation
When we were binding viper values to the cobra flags, it was occuring before the config file was loaded, so if you configured a flag in the config file, it wasn't persisting the correct value to the variable bound to the flag. When the flag was not bound to the global porter Config.Data, such as porter build --no-lint, the configuration file values were not applied. This is the regression describe in getporter#2735 which was caused by apply cobra values to viper too soon (before the config file was loaded). I have split our viper configuration into a three step process: 1. Configure the viper instance, for example binding custom open telemetry environment variables. 2. Bind viper to the cobra flags, AFTER the config file has been loaded. 3. Apply the consolidated configuration in viper (which now contains both cobra flags, env vars and the config file) back to the global config in Config.Data This ensures that viper has all relevant configuration loaded before binding its value back to the original command flags (i.e. our variables in code). Fixes getporter#2735 Signed-off-by: Carolyn Van Slyck <me@carolynvanslyck.com>
carolynvs
force-pushed
the
fix-flag-binding
branch
from
d0ed31d
to
ffca151
Compare
|
The tests are failing due to a different bug (#2744) that I am patching and will cut an immediate release for once we have this in too. |
| }) | ||
|
|
||
| t.Run("env set, cfg set", func(t *testing.T) { | ||
| os.Setenv(expEnvVar, "") |
There was a problem hiding this comment.
Not sure there's a way around setting this env var, but could this interfere with other tests later if they're running in parallel? I don't remember how this works.
There was a problem hiding this comment.
You are totally remembering it right. 👍 This is why at the top of the test I don't call t.Parallel(), and defer unsetting this env var.
porter/cmd/porter/main_test.go
Lines 89 to 92 in ffca151
There was a problem hiding this comment.
I wish testing.Testing had a t.NotParallelSafe() so that I didn't have to leave comments like that around. 😂
There was a problem hiding this comment.
Maybe a good thing to call out in the comments - just for future brains?
There was a problem hiding this comment.
The first line in the test (90) is // do not run in parallel, which is what I have been putting on any test that uses os.SetEnv so that we don't forget and accidentally call t.Parallel().
Or were you thinking about a different spot?
| p := porter.NewTestPorter(t) | ||
| defer p.Close() | ||
|
|
||
| cmd := buildRootCommandFrom(p.Porter) |
There was a problem hiding this comment.
Wonder if it's worth building a variant of this function that takes in key/value pairs as environment vars, so you don't have to set the environment globally in these tests? for example, maybe a buildRootCommandFromEnv can pull params from the env, and call a second buildRootCommandFromArgs which takes explicit parameters, then you could use the latter here.
There was a problem hiding this comment.
Unfortunately in order to use spf13/viper, you need to set OS env vars. Viper doesn't provide (that I know of) a way to mock or load env vars from another source. It wasn't made with testing in mind.
I feel like I'm halfway there to just rewriting the darn library at this point but this is boring non-domain specific code that I don't want to own more than I have to! 😭
|
I'm going to merge since this needs to get released soon but if there are follow-ups we need to make just let me know! |
What does this change
When we were binding viper values to the cobra flags, it was occuring before the config file was loaded, so if you configured a flag in the config file, it wasn't persisting the correct value to the variable bound to the flag.
When the flag was not bound to the global porter Config.Data, such as porter build --no-lint, the configuration file values were not applied. This is the regression describe in #2735 which was caused by apply cobra values to viper too soon (before the config file was loaded).
I have split our viper configuration into a three step process:
This ensures that viper has all relevant configuration loaded before binding its value back to the original command flags (i.e. our variables in code).
What issue does it fix
Fixes #2735
Notes for the reviewer
Put any questions or notes for the reviewer here.
Checklist
Reviewer Checklist