-
Notifications
You must be signed in to change notification settings - Fork 460
Add test for managedclusteradopt controller #5538
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
Add test for managedclusteradopt controller #5538
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #5538 +/- ##
==========================================
+ Coverage 52.93% 53.27% +0.33%
==========================================
Files 272 272
Lines 29485 29485
==========================================
+ Hits 15607 15707 +100
+ Misses 13061 12954 -107
- Partials 817 824 +7 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
cluster-api-provider-azure/controllers/managedclusteradopt_controller.go Lines 172 to 181 in b32f0c6
It doesn't look like we are doing anything with this resource after we patch it, then we create the AzureASOManagedControlPlane. Is this necessary? |
Signed-off-by: Troy Connor <[email protected]>
e1aa91a to
5fd05b1
Compare
|
/retest |
|
/assign @nojnhuh |
I'm not sure I'm following your question, but the |
|
Overall I think an e2e test for this is going to be much more valuable than unit testing the controller. Is that something you're up for? |
In the logic, managedClusterBefore := managedCluster.DeepCopy()
managedCluster.Spec.AgentPoolProfiles = nil
err = r.Patch(ctx, managedCluster, client.MergeFrom(managedClusterBefore))
if err != nil {
return ctrl.Result{}, err
}
managedCluster = &asocontainerservicev1.ManagedCluster{
TypeMeta: metav1.TypeMeta{
APIVersion: asocontainerservicev1.GroupVersion.Identifier(),
Kind: "ManagedCluster",
},
ObjectMeta: metav1.ObjectMeta{
Name: managedCluster.Name,
},
Spec: managedCluster.Spec,
}we patch the managedcluster after we make the Then we shadow the variable Do we need to create a new object when we have the managedCluster already even the before one before the patch?
I definitely agree and can see if I can put that in another PR. I have to see how long that will take me. The unit test here can still be valuable as future changes will allow the test to fail if the functionality changes. |
|
Since |
|
Was this waiting on the integration test? If so, I can add it but didn't know if you wanted that in the same PR. @nojnhuh |
|
/assign |
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
/approve
|
LGTM label has been added. Git tree hash: 42480158eba30e3a8f232e085db095a7ceba3018
|
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: willie-yao 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 |
|
Changes look good to me, thank you @troy0820! We might want to open a new issue to track an e2e test for the adoption flow. Would you be able to do that? |
Yeah I can do that. /retest |
|
Thanks @troy0820 for the test and @willie-yao for getting this in! |
What type of PR is this?
/kind cleanup
What this PR does / why we need it:
Adds testing to the controllers package
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)format, will close the issue(s) when PR gets merged):Fixes #
Part of #3649
Special notes for your reviewer:
TODOs:
Release note: