🌱 Temporary fix for ResourceVersion flake #3601
Conversation
k8s-ci-robot
added
the
cncf-cla: yes
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
the
size/S
|
Fix is fine in general, but I think we want to use it only for the Runtime SDK test, as that is the one that is failing |
fabriziopandini
force-pushed
the
tmp-fix-for-resourceVersion-flake
branch
from
ef3ec53 to
4090cb0
Compare
|
/test ? |
|
@sbueringer: The following commands are available to trigger required jobs: 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-sigs/prow repository. |
|
/test pull-cluster-api-provider-vsphere-e2e-govmomi-blocking-main Let's merge after tests are green. We'll have to ignore the linter because of caching issues |
|
/retest |
|
/cherry-pick release-1.14 |
|
@sbueringer: once the present PR merges, I will cherry-pick it on top of 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-sigs/prow repository. |
|
/retest |
1 similar comment
|
/retest |
|
@sbueringer: new pull request created: #3608 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-sigs/prow repository. |
4 participants
Temporarily ignore resource version changes in VSphereMachine while we found a fix for #3592
Note: we consider this temporary fix ok given that we are validating ResourceVersionStable also in other tests where this flake does not happen (so we don't lose coverage entirely) + from a first investigation this seems more an issue of the test setup than a production code issue.