Closed tizueh closed 3 months ago
When run with env var DEBUG=testcontainers*
i get:
| OCI runtime exec failed: exec failed: unable to start container process: chdir to cwd ("/mnt/c/Projects/E2E/docker-express-react-playwright/e2ev") set in config.json failed: no such file or directory: unknown
Hi, it's actually working for me, could you give more info?
[E2E Tests/e2e-tests] ⭐ Run Main Run E2E tests against local environment
[E2E Tests/e2e-tests] 🐳 docker exec cmd=[bash --noprofile --norc -e -o pipefail /var/run/act/workflow/3] user= workdir=e2e
| yarn run v1.22.22
| $ CI=true yarn e2etest
| $ playwright test ./src
|
| Running 1 test using 1 worker
|
| ✓ 1 [chromium] › index.test.ts:5:5 › should display "Hello, TypeScript Express!" text on page (407ms)
|
| 1 passed (738ms)
| Done in 6.76s.
[E2E Tests/e2e-tests] ✅ Success - Main Run E2E tests against local environment
Also, I didn't know about act
, it's awesome! Thanks for sharing 😄
@cristianrgreco did you checkout the testcontainer branch?
@cristianrgreco did you checkout the testcontainer branch?
I have now and see your issue. This code:
docker run -v $(pwd)/e2e-report:/app/e2e-report --name playwright-tests --network=host playwright-tests yarn e2etest:ci
Is running inside a container. This code will execute Testcontainers which talks to Docker to try and spin up a MySQL container. However within this container there is no access to Docker. You can mount the Docker socket from the host by adding a volume mount: -v /var/run/docker.sock:/var/run/docker.sock
, which Testcontainers will find and use
Thanks, that helped. Is it expected, that starting the MySqlContainer takes about 10 seconds? Is there a way to improve that?
@tizueh Starting a container with await container.start()
will make Testcontainers start the container, and wait until the wait strategy completes. The wait strategy determines when the container is ready to be used.
In the case of MySQL, the wait strategy is to wait until until port 3306
is ready to accept connections. If it is taking 10s for the container to start, then that is simply how long the MySQL container takes to start and make that port available. If this doesn't fit your use case, you can specify your own wait strategy, but I would be careful not to introduce a case where you attempt to use the container before it is ready.
What makes you say that 10s is a long time for the container to start?
For starting up a MySql container 10s seems quite good. But if I do that for every test the overhead gets significant. So if there is no way to improve that I think I have to keep the container alive for longer than only one test.
Ah I see, yes there are several ways to reuse the same container across tests. If you are using Jest/Vitest or another test framework that supports startup/shutdown hooks I'd recommend you start the container there, so it will be reused across all tests. If not there is a withReuse
option, so if you have multiple tests which all attempt to start the MySQL container, if the container configuration is the same and Testcontainers detects that a suitable container is already running, it will reuse it, and if not start it.
Expected Behaviour Testcontainers to be able to start a MySqlContainer without problem.
Actual Behaviour It shows the error "Could not find a working container runtime strategy".
Steps to Reproduce
act pull_request
Environment Information