Closed macalbert closed 3 months ago
Does it fail with 3.7.0
too? Our CI should use the latest patch version too 🤔. Maybe it is a regression from uploading the /etc/mysql/my.cnf
file (#1116) /cc @0xced. I am wondering about:
mysqld: Error on realpath() on '/var/lib/mysql-files' (Error 2 - No such file or directory)
I can take a look at it end of next week.
I've tested it with 3.7.0
, and it's working well. It seems like the issue might not be related to the version itself. Maybe the regression from uploading the /etc/mysql/my.cnf
file, as mentioned in #1116, doesn't affect this version?
I'll keep an eye out for any related errors, but so far, so good.
I just submitted #1144 which should address this issue.
Note that this problem only exist for mysql:8.0.28
and earlier versions. mysql:8.0.29
onwards images have an empty /var/lib/mysql-files
directory and the containers start fine.
This is also the reason why this was not caught by continuous integration since the default image against which the test are run is mysql:8.0
which currently corresponds to mysql:8.0.36
.
@0xced Thanks for the PR. @macalbert you can work around the issue until a new version is available by adding the following line to the builder configuration:
WithResourceMapping(Array.Empty<byte>(), "/var/lib/mysql-files/gh-issue-1142")
This will create the directory upon container start.
Testcontainers version
3.8.0
Using the latest Testcontainers version?
Yes
Host OS
Windows/Ubuntu
Host arch
x86/ARM
.NET version
8.0
Docker version
Docker info
What happened?
When attempting to start a
MySQL 8.0.28
container using Testcontainers 3.8.0, the operation fails with a Docker.DotNet.DockerApiException, indicating that the container is not running. This issue occurs during the execution of integration tests, specifically when trying to establish a connection to the MySQL container.I'm including a simplified test scenario that demonstrates the problem. The test attempts to start a
MySQL 8.0.28
container and then perform two operations: opening a database connection and executing a simple SQL script. Both tests highlight the failure to start the container, as indicated by the Docker.DotNet.DockerApiException.Relevant log output
Additional information
No response