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

Fix binding configuration file settings to command flags #2738

Merged
merged 2 commits into from
Apr 24, 2023

Conversation

carolynvs
Copy link
Member

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:

  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).

What issue does it fix

Fixes #2735

Notes for the reviewer

Put any questions or notes for the reviewer here.

Checklist

  • Did you write tests?
  • Did you write documentation?
  • Did you change porter.yaml or a storage document record? Update the corresponding schema file.
  • If this is your first pull request, please add your name to the bottom of our Contributors list. Thank you for making Porter better! 🙇‍♀️

Reviewer Checklist

  • Comment with /azp run test-porter-release if a magefile or build script was modified
  • Comment with /azp run porter-integration if it's a non-trivial PR

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
Copy link
Member Author

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.

@carolynvs carolynvs marked this pull request as ready for review April 24, 2023 14:41
Copy link
Contributor

@arschles arschles left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. My comments could be in follow-ups

})

t.Run("env set, cfg set", func(t *testing.T) {
os.Setenv(expEnvVar, "")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

func TestExperimentalFlags(t *testing.T) {
// do not run in parallel
expEnvVar := "PORTER_EXPERIMENTAL"
os.Unsetenv(expEnvVar)

Copy link
Member Author

@carolynvs carolynvs Apr 24, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wish testing.Testing had a t.NotParallelSafe() so that I didn't have to leave comments like that around. 😂

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe a good thing to call out in the comments - just for future brains?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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! 😭

Copy link
Contributor

@hypernovasunnix hypernovasunnix left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, had one nit

@carolynvs
Copy link
Member Author

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!

@carolynvs carolynvs merged commit 7f119cb into getporter:main Apr 24, 2023
@carolynvs carolynvs deleted the fix-flag-binding branch April 24, 2023 18:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Porter config file doesn't always bind to the command flag
3 participants