5

There is config for CircleCI. On the local machine, when you run CircleCI, everything passes. In this case, the server is a lot of mistakes, one of them is

java.lang.IllegalStateException: Can not connect to Ryuk

At the same time in the future there is an error connecting tests in containers launched earlier in test-containers, I think this is due to an error connecting to Ryuk. Confuses that fact that on the local machine everything works and on the server everything falls.

  • Alternative and mostly transparent solution described here: https://stackoverflow.com/questions/70650555/circleci-testcontainers-using-docker-executor-with-remote-docker-environment – revau.lt Apr 29 '22 at 12:03

2 Answers2

3

The reason for the problem is here: https://gist.github.com/OlegGorj/52ca84624503a5e85624c6eb38df4590 where it says: Separation of Environments The job and remote docker run in separate environments. Therefore, Docker containers cannot directly communicate with the containers running in remote docker.

Accessing Services It’s impossible to start a service in remote docker and ping it directly from a primary container (and vice versa).

There appear to be three options:

  1. Do your entire build in another remote docker container.
  2. Use a dedicate VM for the build (https://www.testcontainers.org/supported_docker_environment/continuous_integration/circle_ci/)
  3. If you can get away with creating the test container at the start then do that and don't use testcontainers within circleci (https://circleci.com/docs/2.0/executor-types/#using-multiple-docker-images). Just remember that each test case will be interacting with the same instance of the service.

More details on option 3

Basically, don't use testcontainers (one word) when using circleci. In your circleci/config.yaml do something like this:

    jobs:
      build:
          docker:        
            - image: circleci/openjdk:14.0.1-jdk-buster
            - image: rabbitmq:3.8-alpine
          environment:

So circleci runs the rabbit container on the same host as your image. You can then communicate with it on localhost on whatever ports it opens, and circleci will close these secondary containers when your build (which is always in the first container) finishes.

There are a few downsides to this:

  • testcontainers lets you start and stop containers, this approach doesn't so you fundamentally cannot test the restart of a container.
  • all of your tests will run with the same instance so, in the rabbit instance, each test should use a unique exchange and queue.
  • if, like me, you need to build in circleci and on the desktop (and in Jenkins) then you need to have circleci conditional logic in your tests (just check for System.getenv("CIRCLECI")) to determine which approach to take.
Yaytay
  • 493
  • 4
  • 13
  • when you say "create the test containers at the start... and don't use test containers within circleci" what do you mean and how to achieve that? – alex Jul 14 '20 at 16:42
  • Edited my answer to provide more details. – Yaytay Jul 15 '20 at 19:45
2

I had the same error, fixed it by turning off Experimental Features in Docker.

You can find them in Preferences. Experimental Features Docker

Derek MC
  • 366
  • 2
  • 4
  • 25