-
Couldn't load subscription status.
- Fork 7.3k
Validate git protocol config before setting it #2138
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cristiand391 Thanks for starting work on this! I like the initial direction. I can envision future scenarios where we would want to validate other configuration settings, which is why I think this should be made into a more generic solution for validating any key value pair that might be set through the configure command. Initially we can validate just the git_protocol setting but write the code in a way that makes it easy to add more validations in the future. Once we have that in place, we should add some tests for the new functionality.
|
@samcoe Alright, what do you think about this? func ValidateConfig(key, value string) error {
switch key {
case "git_protocol":
if value != "ssh" && value != "https" {
return fmt.Errorf("invalid git protocol")
}
}
return nil
}
...
func (c *fileConfig) Set(hostname, key, value string) error {
if err := ValidateConfig(key, value); err != nil {
return err
}
...If there's an error it will be formated and printed here on pkg/cmd/config/config.go |
|
@cristiand391 That looks like a good direction to me. Stylistically I find reading a map where the key is the configuration key and the value being an array of valid values a bit easier to parse than a huge switch statement. I was thinking something like this: func validConfigEntries(key string) []string {
configEntries := make(map[string][]string)
configEntries["git_protocol"] = []string{"ssh", "https"}
return configEntries[key]
}
func validateConfigEntry(key, value string) error {
validValues := validConfigEntries(key)
if len(validValues) == 0 {
return nil
}
for _, v := range validValues {
if v == value {
return nil
}
}
return fmt.Errorf("%s is not a valid value for %s", value, key)
}What do you think? |
|
@samcoe Actually, I have absolutely zero experience with Go. I actually understand a bit from this code, for I am comfortable with Java, JavaScript and C++ π What I just assume is, a map is basically like an object in JavaScript, that stores some key-value pairs. If I am right, then, this looks like a lot cleaner code to me. |
|
It definitely looks cleaner than using if/else or switch conditionals, thanks ππΎ |
|
Will another property do: |
|
@shrihanDev Yeah, I haven't added it in the last commit so you can open another PR for it if this gets merged. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is really solid, and almost there. I have two last requests:
-
Can we improve the error message coming from
validateConfigEntry? I think it would be super helpful to see a list of valid values that the user can choose from right in the error message so that they don't need to go searching through the documentation to find valid values. -
Can we add some unit tests to
validateConfigEntry? Both to verify its functionality and to make sure that refactors in the future don't break its functionality.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this! Almost there
a237291 to
14a222b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the updates! π
| ) | ||
|
|
||
| var configValues = map[string][]string{ | ||
| "git_protocol": {"ssh", "https"}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, we could also add
"prompt": {"enabled", "disabled"}Maybe, in another PR, we can add more values to this map.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this should probably go in a follow up PR π
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
π This looks great! I like having the caller format the error message, much cleaner.
|
This is ready to be |
Fix #2130
Example: