-
Notifications
You must be signed in to change notification settings - Fork 24
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
feat(cmd): add db's user list #1019
Conversation
d5dd9d1
to
bfcb8bd
Compare
3aa85ce
to
c6a9c35
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.
nice job! some small issues, but nothing too serious
}.Render(), | ||
|
||
Action: func(c *cli.Context) error { | ||
if c.Args().Len() != 1 { |
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.
issue: in this case, an error should be returned. the exit code 0 means the operation was done successfully, which is not the case here
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.
Well the logic we implement in our CLI is more an error meaning CLI itself has failed to do something.
Here we succeed to print the help command because the number of argument is not expected.
It may be debatable, but for the sake of consistency with the rest of CLI, I'll leave it like that.
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.
wtf you're in fact right, but that is weird.. i really thought that there were a client that pointed this behaviour, and that we should handle it differently. this should return an exit code 1, but you are right : consistency is more important
db/users/utils.go
Outdated
scErrors "github.com/Scalingo/go-utils/errors/v2" | ||
) | ||
|
||
var ErrDatabaseNotSupportUserManagement = errors.New("Error: DBMS does not support user management") |
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.
issue: not a fan of making a constant of an error, as we never do this anywhere in our code. we often have a same base error such as "user cannot be fetched", but we do not factorize them
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.
as we never do this anywhere in our code
Not true, just in this repo I can see some, in addition, we usually do it for two main reason:
- use the constant (preferably a typed) to compare an error
- avoid duplication
In this case it's the latter we're interested in
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.
just in this repo I can see some
not really sure about that one as I never saw one in my peregrinations in all our go code. in fact, i like the idea that we centralize our errors, and then identify them more easily. though, i see this more as a consistency issue. if we do this here, we should do it every where errors are duplicated.
this is, though, not blocking
db/users/utils.go
Outdated
return false, scErrors.Wrap(ctx, err, "get the addon to check user management support") | ||
} | ||
|
||
for _, supportedAddon := range supportedAddons { |
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.
praise: i like the simple use of plurals and singular in a foreach
return nil | ||
} | ||
|
||
isPasswordGenerated := false |
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.
issue (blocking?): the password generation logic is made backend sided. do we want to handle it on the client side?
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 agree, the reason of this check here was to return error has early has possible. This means if the username is incorrect there is no need to continue the process (i.e. password, confirmation)
But WDYT?
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.
well that could have remove some complexity client sided, but this isn't really an issue and is not blocking, do as your heart wishes
db/users/create.go
Outdated
func askForPassword(ctx context.Context) (string, string, error) { | ||
fmt.Printf("Password: (Will be generated if left empty) ") | ||
|
||
bytePassword, err := term.ReadPassword(int(os.Stdin.Fd())) |
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.
issue: no need to specify the type of the variable via its name
bytePassword, err := term.ReadPassword(int(os.Stdin.Fd())) | |
password, err := term.ReadPassword(int(os.Stdin.Fd())) |
db/users/create.go
Outdated
} | ||
|
||
fmt.Printf("\nPassword Confirmation: ") | ||
byteConfirmedPassword, err := term.ReadPassword(int(os.Stdin.Fd())) |
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.
issue: same, no need for specifying the type in the variable name
c6a9c35
to
c1d2739
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.
well the last nitpicks are not enough to block my approval, so LGTM! nice job
3ea9edd
to
d0941f5
Compare
d0941f5
to
52f6e47
Compare
List
Delete
Create
Fixes #1018