-
Notifications
You must be signed in to change notification settings - Fork 203
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
Porter config file doesn't always bind to the command flag #2735
Comments
4 tasks
carolynvs
added a commit
to carolynvs/porter
that referenced
this issue
Apr 20, 2023
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 being applied to the flag correctly. It worked fine for environment variables (such as PORTER_NO_LINT) or using the flag directly (such as --no-lint). I have split our viper configuration into a two 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. 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
added a commit
to carolynvs/porter
that referenced
this issue
Apr 20, 2023
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>
4 tasks
carolynvs
added a commit
to carolynvs/porter
that referenced
this issue
Apr 24, 2023
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>
bdegeeter
pushed a commit
to bdegeeter/porter
that referenced
this issue
May 11, 2023
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>
This issue was closed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
When running a porter command that has a flag is defined, and that setting is not globally defined on config.DataStore, configuring the flag in your porter config file doesn't work. Only environment variables and directly setting the flag works.
Context
To Reproduce
Let's pick a flag that is defined on a command that doesn't have a global setting, such as
porter build --no-lint
.porter build --no-lint=true
and note that the build is stopped with a lint error.porter build --no-lint=false
and note that the build is allowed to execute.no-lint: true
.porter build
without specifying the --no-lint flag. Note that the linter is still executed and the build is stopped with a lint error.Expected behavior
The configuration file should automatically set --no-lint to true and the build should be allowed to proceed.
Porter Command and Output
Version
1.0.13
The text was updated successfully, but these errors were encountered: