-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
test updates to help debug #18041 #18043
Conversation
The standard lib states that server handlers don't need to close the body, so let's not do that to avoid any unforeseen side effect. [NO TESTS NEEDED] - existing tests should suffice. Signed-off-by: Valentin Rothberg <[email protected]>
Check the DELETE reports for both deletes. containers#18041 indicates that the pod hasn't been removed which made me suspicious about the 1st delete. Signed-off-by: Valentin Rothberg <[email protected]>
Don't check for `.Pods` field in DELETE reports since they don't exist. Signed-off-by: Valentin Rothberg <[email protected]>
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: vrothberg 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 |
Good catch, thank you. |
@containers/podman-maintainers PTAL |
/lgtm Autotagbot added the "API change" label because the PR touches files under |
I think it got marked as an API change because code in the handler got changed. The API itself remained untouched. @Luap99 PTAL |
/hold cancel |
See individual commits for details. Given the first DELETE didn't actually check if the pod was removed, we may get some better idea on the next flakes.
@edsantiago, that's the best thing I could come up with. PTAL
Does this PR introduce a user-facing change?