Skip to content
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.

Sign up for GitHub

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

Jump to bottom

cli/config: add GetFeature, SetFeature for ConfigFile #4965

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
+77 −0
Open

cli/config: add GetFeature, SetFeature for ConfigFile #4965

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
23 changes: 23 additions & 0 deletions cli/config/configfile/file.go
View file
Open in desktop
Expand Up @@ -351,3 +351,26 @@ func (configFile *ConfigFile) SetPluginConfig(pluginname, option, value string)
delete(configFile.Plugins, pluginname)
}
}

// GetFeature retrieves the given key from the config features map.
func (configFile *ConfigFile) GetFeature(key string) (string, bool) {
if configFile.Features == nil {
Copy link
Member

Choose a reason for hiding this comment

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

Will we need any synchronisation around these?

Also the Features being both exported and having accessors starts to feel "wrong" (admitted, we already have a similar situation for the Plugins field above).

Copy link
Member Author

Choose a reason for hiding this comment

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

Oh! I forgot to hit the submit button before I got up for lunch 🙃 I was about to post a comment asking about whether this made sense or not — I came across the Plugins one while working downstream.

Synchronization would benefit us here, although it's useless unless we implement an actual file lock to prevent concurrent access by different processes, which I think is a bigger concern.

Copy link
Member

Choose a reason for hiding this comment

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

Yeah, this is gonna be more of a problem if more plugins start to manipulate these out of band; more so if it's stored in memory, and now possibly memory state no longer reflecting actual state of the file, think;

  • cli loads config in memory
  • calls plugin -> which may manipulate the config
  • now cli's config in memory is out of sync
  • but cli could write to disk (reverting the changes made by the plugin)

I haven't checked the code locally, but if *ConfigFile here is the struct that includes the json: labels, then I'm guessing these fields were exported because of that (i.e. (un)marshaling requires them to be exported), so probably we can't change that immediately, unless we define separate structs/types (separate types for (un)marshaling than for "in-memory" state; the latter would have un-exported fields and accessors).

Copy link
Member Author

Choose a reason for hiding this comment

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

Hmm, I mostly agree. I think ultimately this is something that will only be "properly" solved by a) having the plugins not change the config directly, but communicate changes over the socket to the CLI and have the CLI process make those changes, and b) implementing a file lock so other processes don't touch the config at the same time.

However, for right now, barring concurrent process access, I think this:

cli loads config in memory
calls plugin -> which may manipulate the config
now cli's config in memory is out of sync
but cli could write to disk (reverting the changes made by the plugin)

Isn't a huge problem since we can know when we're writing the file to disk from the CLI process and can try to make sure we don't do it while the CLI is calling a plugin.

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 can shelve this PR until we have file locking in place, or we can keep it (even in a somewhat incomplete state) to add synchronization, although I don't think that will bring us as much value right now.

return "", false
}
v, ok := configFile.Features[key]
return v, ok
}

// SetFeature sets the key to the given value in the config features map.
// If the features field is nil, it initializes a new map.
// Passing a value of "" will remove the key-value pair from the map.
func (configFile *ConfigFile) SetFeature(key, value string) {
if configFile.Features == nil {
configFile.Features = make(map[string]string)
}
if value != "" {
configFile.Features[key] = value
} else {
delete(configFile.Features, key)
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: if we go for these get/set helpers, i'd probably split out the Delete/RemoveFeature() func as well to both separate the functionality, and also because "setting an empty string" does not really make me think of "removing a key/value pair from a map" (maybe the empty string is a value someone legitimately wants)

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 agree in principle, the reason why I did it that way was for consistency/since it might be confusing to have the features setters work differently than the plugin's –https://github.com/laurazard/cli/blob/b463a15f78e8c74c7f956ab5511d3c3ea60b1d57/cli/config/configfile/file.go#L345-L349

I'm happy to change this though.

Copy link
Contributor

Choose a reason for hiding this comment

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

Oh, I didn't even notice that! No hard feelings here anyway

}
}
54 changes: 54 additions & 0 deletions cli/config/configfile/file_test.go
View file
Open in desktop
Expand Up @@ -602,3 +602,57 @@ func TestPluginConfig(t *testing.T) {
assert.NilError(t, err)
golden.Assert(t, string(cfg), "plugin-config-2.golden")
}

func TestSetFeature(t *testing.T) {
t.Run("new feature", func(t *testing.T) {
configFile := &ConfigFile{}

configFile.SetFeature("foo", "bar")

assert.Equal(t, "bar", configFile.Features["foo"])
})

t.Run("update key", func(t *testing.T) {
configFile := &ConfigFile{}

configFile.SetFeature("foo", "bar")
assert.Equal(t, "bar", configFile.Features["foo"])

configFile.SetFeature("foo", "baz")
assert.Equal(t, "baz", configFile.Features["foo"])
})

t.Run("remove feature", func(t *testing.T) {
configFile := &ConfigFile{}

configFile.SetFeature("foo", "bar")
assert.Equal(t, "bar", configFile.Features["foo"])

configFile.SetFeature("foo", "")
_, exists := configFile.Features["foo"]
assert.Check(t, !exists)
})
}

func TestGetFeature(t *testing.T) {
t.Run("feature exists", func(t *testing.T) {
configFile := &ConfigFile{}
configFile.Features = map[string]string{
"foo": "bar",
}

f, ok := configFile.GetFeature("foo")

assert.Check(t, ok)
assert.Equal(t, "bar", f)
})

t.Run("missing feature", func(t *testing.T) {
configFile := &ConfigFile{}

f, ok := configFile.GetFeature("baz")

assert.Check(t, !ok)
assert.Equal(t, "", f)
})
}