Skip to content

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

Merged
merged 23 commits into from
Jul 28, 2022

Conversation

theganyo
Copy link
Member

@theganyo theganyo commented Jul 25, 2022

Commands added:

registry config [command]

Available Commands:
  configurations Maintain configuration profiles
  get            Print the value of a property.
  list           List properties for the currently active configuration.
  set            Set the value of a property.
  unset          Unset the value of a property.


registry config configurations [command]

Available Commands:
  activate    Activates an existing named configuration.
  create      Creates a new named configuration.
  delete      Deletes a named configuration.
  describe    Describes a named configuration by listing its properties.
  list        Lists existing named configs.

Closes #649

@codecov
Copy link

codecov bot commented Jul 25, 2022

Codecov Report

Merging #671 (c5715d3) into main (7935c83) will increase coverage by 1.40%.
The diff coverage is 74.94%.

@@            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     
Impacted Files Coverage Δ
cmd/registry/cmd/config/configurations/create.go 58.62% <58.62%> (ø)
cmd/registry/cmd/config/configurations/activate.go 60.86% <60.86%> (ø)
pkg/connection/config.go 67.24% <67.24%> (ø)
cmd/registry/cmd/config/unset.go 70.00% <70.00%> (ø)
cmd/registry/cmd/config/configurations/describe.go 75.00% <75.00%> (ø)
cmd/registry/cmd/config/config.go 81.48% <81.48%> (ø)
cmd/registry/cmd/config/configurations/list.go 82.35% <82.35%> (ø)
cmd/registry/cmd/config/set.go 82.35% <82.35%> (ø)
cmd/registry/cmd/config/get.go 86.95% <86.95%> (ø)
cmd/registry/cmd/config/list.go 86.95% <86.95%> (ø)
... and 5 more

Help us with your feedback. Take ten seconds to tell us how you rate us.

@theganyo theganyo requested review from seaneganx and timburks July 25, 2022 19:41
Copy link
Contributor

@seaneganx seaneganx left a 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()
Copy link
Contributor

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?

Copy link
Member Author

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.

Copy link
Member Author

@theganyo theganyo Jul 28, 2022

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

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.

Copy link
Member Author

@theganyo theganyo Jul 26, 2022

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

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.

Copy link
Member Author

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?

@timburks
Copy link
Contributor

@theganyo for a high-level summary, could you edit the PR description to list the commands that are added?

@theganyo
Copy link
Member Author

@theganyo for a high-level summary, could you edit the PR description to list the commands that are added?

done

@timburks
Copy link
Contributor

This may be out of scope for this initial PR but...

What do we want the startup experience to be?

$ registry config list
insecure = false

Your active configuration is: "".

I think here we might want to say "you have no active configuration; see registry config configurations to see how to create and manage configurations`.

$ registry config configurations list
Error: Cannot read configs: open /home/timburks/.config/registry: no such file or directory
Cannot read configs: open /home/timburks/.config/registry: no such file or directory

Maybe: "No configuration directory exists. We expect configurations to be stored in ..."

$ registry config configurations create default
Error: Cannot create config "default": open /home/timburks/.config/registry/default: no such file or directory
Cannot create config "default": open /home/timburks/.config/registry/default: no such file or directory

Should we automatically create the needed directories?

@theganyo
Copy link
Member Author

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 auth/. (Also: We should definitely at least create the directory if it's missing, that was an oversight I will fix now.)

@theganyo
Copy link
Member Author

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: "

@theganyo
Copy link
Member Author

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.

Copy link
Contributor

@seaneganx seaneganx left a 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 {
Copy link
Contributor

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"}.

Copy link
Member Author

Choose a reason for hiding this comment

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

sure

@theganyo theganyo merged commit 6ff58d9 into apigee:main Jul 28, 2022
@theganyo theganyo deleted the theganyo/issue649 branch July 28, 2022 20:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

Add CLI commands to manage config file
3 participants