Hibernate-reactive: os testes pararam de funcionar no desktop Docker

Criado em 4 out. 2020 · 23Comentários · Fonte: hibernate/hibernate-reactive

Não tenho ideia do que está acontecendo aqui, mas parece que coincidiu com a atualização da área de trabalho do Docker no Mac para a versão mais recente:

Gradle Test Executor 2 > org.hibernate.reactive.FilterTest > testFilterCollectionFetch FAILED
    org.testcontainers.containers.ContainerLaunchException: Container startup failed
        at org.testcontainers.containers.GenericContainer.doStart(GenericContainer.java:330)
        at org.testcontainers.containers.GenericContainer.start(GenericContainer.java:311)
        at org.hibernate.reactive.containers.PostgreSQLDatabase.getJdbcUrl(PostgreSQLDatabase.java:39)
        at org.hibernate.reactive.containers.DatabaseConfiguration.getJdbcUrl(DatabaseConfiguration.java:78)
        at org.hibernate.reactive.BaseReactiveTest.constructConfiguration(BaseReactiveTest.java:88)
        at org.hibernate.reactive.FilterTest.constructConfiguration(FilterTest.java:26)

        Caused by:
        org.testcontainers.containers.ContainerFetchException: Can't get Docker image: RemoteDockerImage(imageName=postgres:13.0, imagePullPolicy=DefaultPullPolicy())
            at org.testcontainers.containers.GenericContainer.getDockerImageName(GenericContainer.java:1279)
            at org.testcontainers.containers.GenericContainer.logger(GenericContainer.java:613)
            at org.testcontainers.containers.GenericContainer.doStart(GenericContainer.java:320)
            ... 5 more

            Caused by:
            java.lang.IllegalStateException: Can not connect to Ryuk at localhost:32768
                at org.testcontainers.utility.ResourceReaper.start(ResourceReaper.java:176)
                at org.testcontainers.DockerClientFactory.client(DockerClientFactory.java:168)
                at org.testcontainers.LazyDockerClient.getDockerClient(LazyDockerClient.java:14)
                at org.testcontainers.LazyDockerClient.listImagesCmd(LazyDockerClient.java:12)
                at org.testcontainers.images.LocalImagesCache.maybeInitCache(LocalImagesCache.java:68)
                at org.testcontainers.images.LocalImagesCache.get(LocalImagesCache.java:32)
                at org.testcontainers.images.AbstractImagePullPolicy.shouldPull(AbstractImagePullPolicy.java:18)
                at org.testcontainers.images.RemoteDockerImage.resolve(RemoteDockerImage.java:59)
                at org.testcontainers.images.RemoteDockerImage.resolve(RemoteDockerImage.java:26)
                at org.testcontainers.utility.LazyFuture.getResolvedValue(LazyFuture.java:20)
                at org.testcontainers.utility.LazyFuture.get(LazyFuture.java:27)
                at org.testcontainers.containers.GenericContainer.getDockerImageName(GenericContainer.java:1277)
                ... 7 more

    java.lang.NullPointerException
        at org.hibernate.reactive.BaseReactiveTest.after(BaseReactiveTest.java:156)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at io.vertx.ext.unit.junit.VertxUnitRunner.invokeTestMethod(VertxUnitRunner.java:95)
        at io.vertx.ext.unit.junit.VertxUnitRunner.lambda$invokeExplosively$0(VertxUnitRunner.java:114)
        at io.vertx.ext.unit.impl.TestContextImpl.run(TestContextImpl.java:90)
        at io.vertx.ext.unit.junit.VertxUnitRunner.invokeExplosively(VertxUnitRunner.java:130)
        at io.vertx.ext.unit.junit.VertxUnitRunner.access$000(VertxUnitRunner.java:39)
        at io.vertx.ext.unit.junit.VertxUnitRunner$3.evaluate(VertxUnitRunner.java:217)
        at io.vertx.ext.unit.junit.Timeout$1.evaluate(Timeout.java:45)
        at org.junit.rules.RunRules.evaluate(RunRules.java:20)
        at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
        at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
        at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
        at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
        at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
        at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
        at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
        at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
        at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
        at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
        at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
        at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
        at org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
        at org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:36)
        at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
        at org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:33)
        at org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:94)
        at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
        at org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:119)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:36)
        at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
        at org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:182)
        at org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:164)
        at org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:414)
        at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
        at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:56)
        at java.lang.Thread.run(Thread.java:748)

Alguma ideia @Sanne , @DavideD ?

bug testing

Fonte

gavinking

Comentários muito úteis

Mudar para testcontainers 1.15.0-rc2 parece ter corrigido isso para mim.

gavinking em 4 out. 2020

👍3

Todos 23 comentários

O que é um Ryuk e por que deveria estar rodando em localhost: 32768?

gavinking em 4 out. 2020

Oh, espere, acabei de encontrar isso: https://github.com/testcontainers/testcontainers-java/issues/3241

gavinking em 4 out. 2020

PosgreSQL lançou recentemente a versão 13, então reconfigurei nossas imagens de teste para usar a imagem postgres:13.0 . Parece que você não consegue fazer o download?

Estranho, supostamente não é diferente de buscar as versões anteriores.

Sanne em 4 out. 2020

PosgreSQL lançou recentemente a versão 13, então reconfigurei nossas imagens de teste para usar a imagem postgres:13.0 . Parece que você não consegue fazer o download?

Acho - mas não tenho certeza - que já estava funcionando no Postgres 13 até atualizar o Docker.

gavinking em 4 out. 2020

É a primeira vez que ouço falar de Ryuk .. das poucas referências de documentos que encontrei, parece que um servidor local opcional deve ser iniciado?
Ele é responsável por buscar imagens em nome dos Testcontainers - portanto, não ter um novo container (como o postgresql 13) acionaria isso.

Parece um bug no Testcontainers.

Você pode conseguir contornar isso baixando o contêiner uma vez manualmente?

Experimente

docker run --rm -it --name HibernateTestingPGSQL \
    -e POSTGRES_USER=hreact -e POSTGRES_PASSWORD=hreact -e POSTGRES_DB=hreact \
    -p 5432:5432 postgres:13.0

Sanne em 4 out. 2020

Mudar para testcontainers 1.15.0-rc2 parece ter corrigido isso para mim.

gavinking em 4 out. 2020

👍3

Legal.
Alternativamente: https://www.testcontainers.org/features/configuration/#disabling -ryuk

Sanne em 4 out. 2020

👍1

Alternativamente: https://www.testcontainers.org/features/configuration/#disabling -ryuk

Sim, funcionou.

Existe uma maneira certa de definir uma variável de ambiente a partir do script do Gradle?

gavinking em 4 out. 2020

Pelo visto:

test {
    environment "TESTCONTAINERS_RYUK_DISABLED", "true"

gavinking em 4 out. 2020

certo, isso deve bastar.

BTW, por favor, aguarde alguns minutos :) a versão está em execução

Sanne em 4 out. 2020

👍1

Lançamento feito .. Vou fazer as atualizações do Quarkus agora.

Sanne em 4 out. 2020

Lançamento feito .. Vou fazer as atualizações do Quarkus agora.

Excelente!

gavinking em 4 out. 2020

Isso ainda é um problema?

DavideD em 13 out. 2020

Acredito que o bug ainda esteja lá, mas as únicas pessoas que irão experimentá-lo são as pessoas que ainda não obtiveram a coisa obtida em sua máquina local.

gavinking em 13 out. 2020

Então, eu me pergunto se isso foi causado pela necessidade de atualizar o banco de dados de teste ao migrar do Postgres 12 para o 13?

Veja, eu tenho testcontainers.reuse.enable=true definido, que talvez reutilize o banco de dados entre execuções de teste?

gavinking em 26 out. 2020

Não acredito que _necessidade_ estritamente dessa atualização para o PostgreSQL 13.

AFAIR quando o atualizei, não precisei fazer nenhuma alteração relacionada, então espero que tudo funcione bem no 12 também - a menos que uma regressão tenha sido incluída nesse meio tempo, mas isso parece menos provável do que ter alguns problemas com docker / testcontainers.

Sanne em 26 out. 2020

Talvez tente reverter a configuração para 12 e veja?

Sanne em 26 out. 2020

Estou passando por isso de novo :-(

Veja, eu tenho testcontainers.reuse.enable=true definido, que talvez reutilize o banco de dados entre execuções de teste?

Eu o configurei como falso e não corrigiu o problema.

gavinking em 6 nov. 2020

environment "TESTCONTAINERS_RYUK_DISABLED", "true"

Isso consertou novamente.

@Sanne Você acha que eu deveria empurrar essa mudança para o script do Gradle?

gavinking em 6 nov. 2020

sim claro por que não. Parece ser um novo recurso, e estamos felizes até agora sem ele.

Sanne em 6 nov. 2020

Ele é responsável por buscar imagens em nome dos Testcontainers - portanto, não ter um novo container (como o postgresql 13) acionaria isso.

Na verdade, ele é responsável por encerrar os contêineres após a execução dos testes. Se você matar a JVM, os ganchos de desligamento não serão executados e os contêineres continuarão em execução, criando contêineres pendentes.
A variável de ambiente existe para sistemas CI onde o Ryuk não pode ser usado (por exemplo, BitBucket Pipelines), mas eles garantem a limpeza por conta própria.

tl; dr: não desabilite o Ryuk;)

bsideup em 7 nov. 2020

Se você matar a JVM, os ganchos de desligamento não serão executados e os contêineres continuarão em execução, criando contêineres pendentes.

Bem, TBH, eu corro com testcontainers.reuse.enable=true sempre, então acho que é o que acontece de qualquer maneira.

E, no geral, balançar contêineres é menos pior do que meus testes simplesmente não rodar. :-)

Mas, claro, se isso for corrigido no 1.15 (que acabou de sair há dois dias, eu acho), isso é ótimo, e vamos apenas fazer o upgrade.

gavinking em 7 nov. 2020

Obrigado por explicar que @bsideup !

Sanne em 7 nov. 2020

Esta página foi útil?

0 / 5 - 0 avaliações

Questões relacionadas

session.remove && session.getReference

Xset-s · 3Comentários

Suporte a ReactiveStreams e Java 9 Flow API

hantsy · 7Comentários

hibernate.jdbc.time_zone não suportado em colunas TIME

pqab · 21Comentários

Investigue como criar um template para JBang para ajudar com relatórios de bugs

DavideD · 31Comentários

Exemplo falha com ORM 5.4.24

DavideD · 37Comentários