-
Notifications
You must be signed in to change notification settings - Fork 47
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
🌱 Use server side apply to update test resource #791
🌱 Use server side apply to update test resource #791
Conversation
Signed-off-by: Mikalai Radchuk <mradchuk@redhat.com>
✅ Deploy Preview for olmv1 ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
|
||
ocv1alpha1 "github.com/operator-framework/operator-controller/api/v1alpha1" | ||
) | ||
|
||
func TestClusterExtensionPackageUniqueness(t *testing.T) { | ||
ctx := context.Background() | ||
fieldOwner := client.FieldOwner("operator-controller-e2e") |
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 think using SSA is valid and maybe we should have a wider discussion about how best to use it in e2e tests. But, we shouldn't be seeing conflicts of the type in the issue coming out of our test code. If we do it's because we forgot to get the latest from the server after a create or update. SSA is nice because it makes things feel more natural for e2e tests. Do we need to respect any conventions when using SSA? Should we switch all mutating interactions in e2e over to SSA?
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 - on a general note we may want to consider best practices (if any) around SSA that we should respect in the e2es
Description
Deals with a flake such as this:
Was introduced in #785.
Reviewer Checklist