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
Fix velerobackup tests for DeepEquals #1415
Fix velerobackup tests for DeepEquals #1415
Conversation
/assign @dgoodwin |
Looks great ty for cleaning this up. /lgtm |
This is a partial revert of c7d6052, which worked around a [breaking change in controller-runtime 0.8.0](kubernetes-sigs/controller-runtime#1306). A subsequent commit will fix the tests to disregard ResourceVersion.
Several tests were using DeepEquals (under testify's `assert.Equal`) to compare a runtime.Object from the (fake) kube server to a locally-constructed expected value. This is brittle, as fields such as ResourceVersion cannot be relied on to have predictable values. With this commit, we switch to a comparison that disregards ResourceVersion and TypeMeta.
03d4b50
to
d5c3190
Compare
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: 2uasimojo, dgoodwin 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 |
/retest Please review the full test history for this PR and help us cut down flakes. |
3 similar comments
/retest Please review the full test history for this PR and help us cut down flakes. |
/retest Please review the full test history for this PR and help us cut down flakes. |
/retest Please review the full test history for this PR and help us cut down flakes. |
Several tests were using DeepEquals (under testify's
assert.Equal
) to compare a runtime.Object from the (fake) kube server to a locally-constructed expected value. This is brittle, as fields such as ResourceVersion cannot be relied on to have predictable values.Commit c7d6052 in #1407 worked around the problem by explicitly setting the ResourceVersion to the value set by the fake kube server in controller-runtime 0.8.x. This PR has two commits: