-
Notifications
You must be signed in to change notification settings - Fork 39.4k
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
managedfields: A few improvements which will make testing easier #116973
managedfields: A few improvements which will make testing easier #116973
Conversation
Please note that we're already in Test Freeze for the Fast forwards are scheduled to happen every 6 hours, whereas the most recent run was: Tue Mar 28 16:29:22 UTC 2023. |
/hold This is still a WIP, not sure if we want that. |
/triage accepted |
In tests specifically, we usually need to create a fieldmanager from a test client (either the embedded or the one that loads from files). This creates the testConverter and then you can use it to create a specific field manager for test. It could be even more convenient but I'm not quite sure what the right thing to do is here. |
7eeba28
to
e342d11
Compare
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.
/lgtm
version check refactors seems orthogonal but looks OK. NewFakeFieldManager
and NewTypeConverter
lgtm
|
||
// NewVersionCheckManager creates a manager that makes sure that the | ||
// applied object is in the proper version. | ||
func NewVersionCheckManager(fieldManager Manager, gvk schema.GroupVersionKind) Manager { |
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.
how does version check manager help testability. seems like an orthogonal change
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.
Yes, so, in tests, it's very unlikely that we will have one FieldManager per individual type like we do in the apiserver. And at least the SkipProbababilityManager (for now, but I expect more are going to have the same problem) was struggling to create a new object because of that. Hiding the GVK makes some things easier.
LGTM label has been added. Git tree hash: be8c24e68da0463d51591e347f184ffb69d8bad0
|
Allows creating a typeconverter from a client (i.e. by taking the data of the client and formatting it so that one can create a type converter).
And simplify how a lot of the fakes are created. Notably, the converter was never really used to do anything so this is simplified.
Let's remove the dependency on the GVK in SkipNonApplied internal manager, since we can deduce the type from the given object.
e342d11
to
b81cfb9
Compare
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.
Nit on documentation. You can fix it next time if you agree.
/lgtm
/approve
"k8s.io/kube-openapi/pkg/validation/spec" | ||
) | ||
|
||
func NewTypeConverter(client Client, preserveUnknownFields bool) (managedfields.TypeConverter, error) { |
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.
Nit: Should there be documentation for this function?
LGTM label has been added. Git tree hash: f2438b669f22972f7f2f2e50a47c8cac2bfb63a6
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: alexzielenski, apelisse, arimallick, seans3 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 |
/hold cancel I think we're good with this. |
Allows creating a typeconverter from a client (i.e. by taking the data of the client and formatting it so that one can create a type converter).
I'm trying to see if that's what we want, possible alternatives:
This needs tests.
What type of PR is this?
/kind cleanup
What this PR does / why we need it:
Which issue(s) this PR fixes:
Nothing
Special notes for your reviewer:
Does this PR introduce a user-facing change?
/assign @alexzielenski