-
Notifications
You must be signed in to change notification settings - Fork 90
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: wait on new image tag #1907
Conversation
Ding ding ding, fails in some cases still so this needs to be conditional |
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.
Ah, you are saying the "contains my-busybox" isn't specific enough? But the parent image shouldn't be shown in the "tr", just in the info below. 🤔 This smells funny, and also fails on some OSes. Let's figure out Monday.
The image has two tags, but which one is shown is not predictable which is the issue shown in the failing tests. Either the UI does not update or it is unpredicable. |
Cool this works now |
testDownloadImage flaked a very often as the test succeeds when runs fast enough. Tagging an image to a new name in this case sometimes changes the image list name to `copybox` instead of `my-busybox which causes the test to flake.
2348edb
to
ee68115
Compare
this looks like flake, /me leans on retry button |
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.
Ah, makes sense -- UI has the same order as .RepoTags
Yup, apparently that is not deterministic :D |
testDownloadImage flaked a very often as the test succeeds when runs fast enough. Tagging an image to a new name in this case changes the image list name to
copybox
possibly because it is sorted beforemy-busybox
.Alternatively we can wait on either?