-
Notifications
You must be signed in to change notification settings - Fork 43
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
Added minder provider update CLI command. #3676
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.
This is great. I left some minor comments inline but I'm approving nonetheless so you can go ahead and merge.
//nolint:lll | ||
GitHub *minderv1.GitHubProviderConfig `json:"github,omitempty" yaml:"github" mapstructure:"github" validate:"required"` | ||
//nolint:lll | ||
GitHubApp *minderv1.GitHubAppProviderConfig `json:"github_app,omitempty" yaml:"github_app" mapstructure:"github_app" validate:"required"` |
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.
Do you have any thoughts on how would we handle additional custom providers?
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 haven't looked too much into this, but I believe that custom providers should ship their configuration structure as some form of spec (e.g. JSON Spec) so that every client can perform validation and guarantee type safety when parsing/producing a config object. That would also make it possible to dynamically produce valid attribute names as help strings for example.
An additional benefit of this is that we could probably get rid of reflection altogether by walking over the spec rather than Go structs.
Moreover, configuration structure is a problem already, because it's untyped outside of Minder Server, which is why I had to duplicate that struct. I think for our main providers we should be already shipping a spec for the config, and allow (or mandate) custom providers to do the same in the future.
Update command allows changing configuration for provider on a per-field basis. It operates on a read-modify-write fashion, retrieving current configuration from the backend for modification. Modification is done by reflection by walking over the struct's JSON tags. Implementation is recursive, but the maximum depth is determined by the deepest field in the configuration struct. Argument parsing is trivial and assumes that arguments are either of the form `field1.field2.field3` (for `--unset-attribute`) or field1.field2.field3=value` (for `--set-attribute`). The right parser for `value` is determined once the correct struct field is found. It is not currently possible to modify `"github-app"` or `"github"` fields. Fixes #3509
The command minder provider update operates on a per-provider basis, which requires the name to be mandatory.
Summary
Update command allows changing configuration for provider on a per-field basis. It operates on a read-modify-write fashion, retrieving current configuration from the backend for modification.
Modification is done by reflection by walking over the struct's JSON tags. Implementation is recursive, but the maximum depth is determined by the deepest field in the configuration struct.
Argument parsing is trivial and assumes that arguments are either of the form
field1.field2.field3
(for--unset-attribute
) orfield1.field2.field3=value
(for--set-attribute
). The right parser forvalue
is determined once the correct struct field is found.It is not currently possible to modify
"github-app"
or"github"
fields.Fixes #3509
Change Type
Mark the type of change your PR introduces:
Testing
Review Checklist: