Skip to content
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

FAILURE after 0.321s: test/cmd/images.sh:108: executing 'oc get istag/tag:1 -o jsonpath={.image.dockerImageReference}' expecting success and text 'wildfly.*@sha256:': the output content test failed #16468

Closed
0xmichalis opened this issue Sep 21, 2017 · 4 comments · Fixed by #16508
Assignees
Labels
component/imageregistry kind/test-flake Categorizes issue or PR as related to test flakes. priority/P1

Comments

@0xmichalis
Copy link
Contributor

https://openshift-gce-devel.appspot.com/build/origin-ci-test/pr-logs/pull/batch/test_pull_request_origin_cmd/3249/

/kind test-flake
/area image
@bparees @mfojtik

@openshift-ci-robot openshift-ci-robot added the kind/test-flake Categorizes issue or PR as related to test flakes. label Sep 21, 2017
@bparees
Copy link
Contributor

bparees commented Sep 21, 2017

This looks like a race condition, we modified the wildfly tag to be from mysql:

os::cmd::expect_success "oc patch istag/wildfly:latest -p='{\"tag\":{\"from\":{\"kind\":\"DockerImage\",\"name\":\"mysql:latest\"}}}'"

then a bit later we turn on scheduled importing:

os::cmd::expect_success "oc patch istag/wildfly:latest -p='{\"tag\":{\"importPolicy\":{\"scheduled\":true}}}'"

then we create tag:1 from wildfly:latest:

os::cmd::expect_success 'oc create imagestreamtag tag:1 --from=wildfly:latest'

and then expect tag:1 to still point to wildfly:

os::cmd::expect_success_and_text 'oc get istag/tag:1 -o jsonpath={.image.dockerImageReference}' 'wildfly.*@sha256:'

but if the scheduled import happened, it's going to point to mysql instead.

It's not terribly obvious to me what this is testing:

os::cmd::expect_success "oc patch istag/wildfly:latest -p='{\"tag\":{\"importPolicy\":{\"scheduled\":true}}}'"
os::cmd::expect_success_and_text 'oc get istag/wildfly:latest -o jsonpath={.tag.importPolicy.scheduled}' 'true'

So i'm somewhat inclined to just delete it. I guess we could also just set it back to false immediately after setting it to true.

@soltysh @dmage @dmage @miminar thoughts/background on this test?

@bparees bparees self-assigned this Sep 21, 2017
@soltysh
Copy link
Member

soltysh commented Sep 22, 2017

My personal recommendation would be to split those tests into two separate one, rather then deleting. As usual I'll be hesitant to remove test, but 👍 for fixing it.

@bparees
Copy link
Contributor

bparees commented Sep 22, 2017

My personal recommendation would be to split those tests into two separate one, rather then deleting. As usual I'll be hesitant to remove test, but 👍 for fixing it.

I would normally agree, but I don't see what this is "testing". It's just doing a patch to a resource and confirming the patch was set. Surely we have patch testing elsewhere, and we have scheduled import testing elsewhere?

@soltysh
Copy link
Member

soltysh commented Sep 22, 2017

Good point, do it then.

openshift-merge-robot added a commit that referenced this issue Sep 25, 2017
Automatic merge from submit-queue (batch tested with PRs 16534, 16533, 16510, 16508, 16392)

remove scheduled import patch test

fixes #16468
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component/imageregistry kind/test-flake Categorizes issue or PR as related to test flakes. priority/P1
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants