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
Simplify flag and configfile parsing & add tests #6244
Simplify flag and configfile parsing & add tests #6244
Conversation
I see that you removed the tests for the flag precedence in this PR. Should we still have a unit test to verify that the behavior we want with this change is preserved? |
e574c85
to
3d45871
Compare
3d45871
to
1142782
Compare
1142782
to
3df750a
Compare
3df750a
to
b0d2d09
Compare
fe3c29d
to
0429a47
Compare
0429a47
to
955db5a
Compare
dfdbeb8
to
b521198
Compare
Signed-off-by: Tim Ramlot <42113979+inteon@users.noreply.github.com>
b521198
to
f1b8952
Compare
@@ -0,0 +1,190 @@ | |||
/* |
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 file replaces controller_test.go
I added some tests that helped me build confidence in this approach. |
Looks good to me! Great improvement! |
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.
Sorry Tim,
I can't understand what's going on here.
You'll need to add some comments explaining how it all works.
Especially where you're supplying functions as arguments with names like fn
.
I see that Cody has already approved it and I trust that he knows the context.
So I'll add a lgtm in case you just want to merge it anyway.
/lgtm
/hold
Signed-off-by: Tim Ramlot <42113979+inteon@users.noreply.github.com>
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.
Thanks Tim,
Thanks for the tests. I didn't see those before.
And thanks for the comments, explaining the "Why" in the code.
As I said during the morning standup, I think it would be more logical if the code specifically parsed the --config
option first, then parsed the config file, then parsed the remaining CLI options.
OR
That the options are all parsed at once into a sparse structure, where every field is a pointer, so that we know definitively which CLI options have been supplied.
Then merge those into the field values that have been parsed from the config file, if one was supplied.
It sounds like that's not currently possible with Cobra.
So I'll lgtm this.
/lgtm
/hold incase you have a response to my question about the validation of the config file.
{ | ||
yaml: ` | ||
apiVersion: controller.config.cert-manager.io/v1alpha1 | ||
kind: ControllerConfiguration | ||
kubeConfig: "<invalid>" | ||
`, | ||
args: func(tempFilePath string) []string { | ||
return []string{"--config=" + tempFilePath, "--kubeconfig=valid"} | ||
}, | ||
expConfig: configFromDefaults(func(tempDir string, cc *config.ControllerConfiguration) { | ||
cc.KubeConfig = "valid" | ||
}), | ||
}, |
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.
You've used the values <invalid>
and valid
.
Do you intend to demonstrate that an invalid value can be used in the config file,
if a valid value has been supplied on the config file?
I think that both the config file and the command line values should validated.
An invalid configfile should be rejected, regardless of the options supplied on the command line.
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.
Invalid
, valid
was already used in the original test code: https://github.com/cert-manager/cert-manager/pull/6244/files/48cc19bee3ede809be80a5295c2daacc19f0071c#diff-41e02d5cc47d0e9e7b0461d73abb901804809b9de11a77596f5565656892457bL26-L40
I think the validation part is lacking anyway and should be improved in a future PR.
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: inteon, wallrj The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/unhold |
Pull Request Motivation
The current approach requires a lot of workarounds. This PR introduces an alternative shorter workaround.
For context: the problem we want to fix is that in order to load the configfile, we have to parse the "--config" flag. Also, the flags should overwrite the configfile options.
The solution: 1. we parse all flags; 2. we load the configfile; 3. we re-parse the flags
The PR also includes some beautiful tests that validate this behavior.
Kind
/kind cleanup
Release Note