-
Notifications
You must be signed in to change notification settings - Fork 66
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
WINC-818: [test] Fix upgradeable condition test #1283
WINC-818: [test] Fix upgradeable condition test #1283
Conversation
Skipping CI for Draft Pull Request. |
aad9a6a
to
333dd14
Compare
/test aws-e2e-upgrade |
/test aws-e2e-upgrade |
333dd14
to
852b108
Compare
/test aws-e2e-upgrade |
1 similar comment
/test aws-e2e-upgrade |
6f3a7a7
to
1004e4a
Compare
/test aws-e2e-upgrade |
1004e4a
to
7ff6ab4
Compare
/test aws-e2e-upgrade |
7ff6ab4
to
8f578f1
Compare
/test aws-e2e-upgrade |
/cherry-pick release-4.12 |
@mansikulkarni96: once the present PR merges, I will cherry-pick it on top of release-4.12 in a new PR and assign it to you. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
8f578f1
to
c62d05e
Compare
/test aws-e2e-upgrade |
1 similar comment
/test aws-e2e-upgrade |
a0f9978
to
a006c3e
Compare
a006c3e
to
be90797
Compare
be90797
to
cd56ac7
Compare
test/e2e/validation_test.go
Outdated
return err | ||
} | ||
// Get the operator condition name using the deployment spec | ||
ocName := deployment.Spec.Template.Spec.Containers[0].Env[3].Value |
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.
Is it safe to get these values by index? Will the operator condition name always be in the third position?
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.
that has been my observation but I think it will be safer to loop through and find the env var by key, will update.
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.
Also the Container[0]
-- is it worth looping over containers and filtering for the the desired one by name?
test/e2e/validation_test.go
Outdated
return err | ||
} | ||
// Get the operator condition name using the deployment spec | ||
ocName := deployment.Spec.Template.Spec.Containers[0].Env[3].Value |
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.
Also the Container[0]
-- is it worth looping over containers and filtering for the the desired one by name?
test/e2e/validation_test.go
Outdated
specCheck := condition.Validate(oc.Spec.Conditions, operators.Upgradeable, expected) | ||
statusCheck := condition.Validate(oc.Status.Conditions, operators.Upgradeable, expected) | ||
return specCheck && statusCheck, nil | ||
return condition.Validate(oc.Status.Conditions, operators.Upgradeable, expected), nil |
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.
Any reason to move to away from checking both spec and status? I felt that checking both was important since the upgradeable condition changes so often, we should ensure it has settled at the expected state (i.e. spec == status == expected
).
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.
good point, I was thinking why it wasn't available in the object. I realised I was using the v1 client, switched to v2 now and I see conditions in spec now. Updating this as well.
15ff2ec
to
6b8c64e
Compare
@mansikulkarni96: once the present PR merges, I will cherry-pick it on top of release-4.10 in a new PR and assign it to you. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/retest-required |
1 similar comment
/retest-required |
7261ec8
to
a025a3a
Compare
go get github.com/operator-framework/operator-lifecycle-manager/pkg/api/client/clientset/versioned go mod tidy && go mod vendor
This commit fixes an issue where the upgradeable condition was not being tested in the e2e test suite. This was the case because the OPERATOR_CONDITION_NAME env var is not being set in the CI env when using the OLM upgrade workflow. The recommendation to fix this was to instead get it from the deployment spec as the condition is present once the operator is deployed. The cache client had to be replaced with the OLM client to get the operator condition using current context.
a025a3a
to
0ffe33d
Compare
/retest-required |
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
I think it's worth noting that a side effect of this PR is that the e2e suite will fail if the operator is not deployed through OLM (this shouldn't affect end users though).
I would like to clarify though the test modified through this PR is testable when running the test suite locally as well as CI through the hack script. |
/retest required |
@mtnbikenc: The
The following commands are available to trigger optional jobs:
Use
In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/retest-required |
1 similar comment
/retest-required |
@mansikulkarni96: all tests passed! Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
@mansikulkarni96: #1283 failed to apply on top of branch "release-4.11":
In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
@mansikulkarni96: #1283 failed to apply on top of branch "release-4.10":
In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
@mansikulkarni96: new pull request created: #1317 In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
@mansikulkarni96 should this be backported to 4.9 as well (since #618 is also in 4.9)? |
yes it should looking into the failed backports as well. |
/cherry-pick relase-4.11 |
@mansikulkarni96: cannot checkout In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
@mansikulkarni96: #1283 failed to apply on top of branch "release-4.11":
In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
This PR fixes an issue where the upgradeable condition was not being tested in the e2e test suite. This was the case because the OPERATOR_CONDITION_NAME env var is not being set in the CI env when using the OLM upgrade workflow. The recommendation to fix this was to instead get it from the deployment spec as the condition is present once the operator is deployed. The cache client also had to be replaced with the OLM client to get the operator condition using current context.