-
Notifications
You must be signed in to change notification settings - Fork 34
Add CLI commands to manage config file #671
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
Codecov Report
@@ Coverage Diff @@
## main #671 +/- ##
==========================================
+ Coverage 54.15% 55.56% +1.40%
==========================================
Files 78 88 +10
Lines 7336 7699 +363
==========================================
+ Hits 3973 4278 +305
- Misses 2940 2966 +26
- Partials 423 455 +32
Help us with your feedback. Take ten seconds to tell us how you rate us. |
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.
Lots of questions and some suggestions.
|
||
// Flags defines Flags that may be bound to a Configuration. Use like: | ||
// `cmd.PersistentFlags().AddFlagSet(connection.Flags)` | ||
var Flags *pflag.FlagSet = createFlagSet() |
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.
Can we avoid relying on global state 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.
Maybe. I'll look into it.
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 actually seems a bit tricky... Instead of trying to rework it right now, we could potentially change access to the FlagSet via a public accessor for now instead of the public variable... That would at least give us a point of control for future work. Otherwise, I think this will be a significant refactor that should probably also incorporate the separating the config and client concerns mentioned in the other comment - and maybe in a follow up PR?
settings, _ := connection.ReadSettings("") | ||
if settings.Address != "" && settings.Validate() == nil { | ||
log.Printf("Client will use remote registry at: %s", settings.Address) | ||
config, _ := connection.ReadConfig("") |
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.
If ReadConfig
truly never returns an error when the argument is ""
, I think we should have a different function (without the empty argument and unused return value) for this purpose.
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.
It can return an error, I just don't care in this case. I added a comment.
func NewRegistryClient(ctx context.Context) (RegistryClient, error) { | ||
settings, err := ActiveSettings() | ||
config, err := ActiveConfig() |
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.
Have we considered removing this "on demand" loading of config values? In most (all?) cases we create one client at the start of the program and pass it along to anywhere it's needed. By loading the config once and setting up the client accordingly, we might be able to eliminate quite a bit of code.
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'm unsure where we'd save a lot of code, but I generally like the idea of separating the concerns. We should maybe look at that in another issue, though?
@theganyo for a high-level summary, could you edit the PR description to list the commands that are added? |
done |
This may be out of scope for this initial PR but... What do we want the startup experience to be?
I think here we might want to say "you have no active configuration; see
Maybe: "No configuration directory exists. We expect configurations to be stored in ..."
Should we automatically create the needed directories? |
Yes, this PR hadn't been intended to address installation... but it's a very good question that we need to answer. I think we should think about automatically creating or having the option to create the same configurations that we put into |
Also: Instead of telling the user to go do another thing, how about we address it more directly like, "You have no configurations. Please enter a configuration name to create: " |
On second thought, I think I like your idea better: Directing the user to another command may not be the most convenient, but putting the client into a new mode may be jarring and could cause scripts to hang. |
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.
Please remove the dead code before submitting (see the linter annotation).
_, err = capture(cmd, "") | ||
if err.Error() != `Config has no property "test".` { | ||
want := `Config has no property "test".` | ||
if err := cmd.Execute(); err.Error() != want { |
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.
Can we compare error values instead of hardcoding a string? In other words, can we make sure this test will pass even if we change the error message? Maybe that means defining type MissingPropertyError struct{field string}
and checking if err != MissingPropertyError{"test"}
.
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.
sure
Commands added:
Closes #649