-
-
Notifications
You must be signed in to change notification settings - Fork 245
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
[Bug]: Unable to locate Dockerfile on v3.8.0 #1143
Comments
Hm, this is unfortunate. I am not running into this issue in my demos or tests. We need more information to figure out what is going wrong. Testcontainers creates a tarball of the Dockerfile directory and sends it to the daemon. This tarball must contain the Dockerfile If that does not help, we need to look into the tarball. Set a breakpoint here or stop at the exception and navigate to the tarball in the |
@HofmeisterAn This is interesting because I have been having issues with |
The previous version contained a bug; 3.8.0 addresses it (#1122). |
@HofmeisterAn https://github.com/davist-ir/Sandbox Here is a reproducible solution. There is a Some things I noticed while putting this together and testing what you said originally. There is an entry in the |
The
Testcontainers does this too. We make sure that the Dockerfile passed to the builder is included as well. I guess the |
This makes sense to me. I was actually surprised to find the
I can. Here is the PR for the repo. Making that change does seem to fix the issue. davist-ir/Sandbox#1 |
Probably the simplest thing we can do is to add the negate pattern twice, with and without the preceding |
@HofmeisterAn I'm not going to pretend I fully understand the ins and outs of the
It grabs the "relative path" from the absolute path and then uses that to compare/match with the With that said, for now, I am simply changing the |
👍 Ah, then it is the other way around.
Not sure if I am missing something, but this will ensure that the Dockerfile will definitely be included, in case it gets excluded by "accident" from a previous ignore entry. But I agree, it is difficult to say if that is the appropriate fix. Thanks for the further investigation. That helps a lot to finally sort it out.
Happy to help 👍. |
Testcontainers version
3.8.0
Using the latest Testcontainers version?
Yes
Host OS
Windows
Host arch
x64
.NET version
6.0.27
Docker version
Client: Cloud integration: v1.0.35+desktop.10 Version: 25.0.3 API version: 1.44 Go version: go1.21.6 Git commit: 4debf41 Built: Tue Feb 6 21:13:02 2024 OS/Arch: windows/amd64 Context: default Server: Docker Desktop 4.27.2 (137060) Engine: Version: 25.0.3 API version: 1.44 (minimum version 1.24) Go version: go1.21.6 Git commit: f417435 Built: Tue Feb 6 21:14:25 2024 OS/Arch: linux/amd64 Experimental: false containerd: Version: 1.6.28 GitCommit: ae07eda36dd25f8a1b98dfbf587313b99c0190bb runc: Version: 1.1.12 GitCommit: v1.1.12-0-g51d5e94 docker-init: Version: 0.19.0 GitCommit: de40ad0
Docker info
What happened?
As part of our test projects with Testcontainers, we build the Docker image from the Dockerfile of the service in the solution. This has been working since a feature was added to Testcontainers to read the Dockerfile and pull down dependent images in the multistage build.
See below for an example Dockerfile:
Example of the
IImage
implementation:This has not changes for a bit now, but as we are upgrading from v3.7.0 to v3.8.0, we are experiencing an issue. See below for the exception that is thrown when running the tests.
This seems to be the root of the issue. When Testcontainers goes to create the image, it is unable to locate the
Dockerfile
. It seems the code that is actually throwing the issue is inDocker.DotNet
package, but I'm not sure if it is an issue in there or Testcontainers.DotNet.Expected Behavior
The excepted behavior is to locate the
Dockerfile
, read it and see that it has dependent images, pull the dependent images, and then build the image using theDockerfile
. This is how it works in v3.7.0.Relevant log output
No response
Additional information
No response
The text was updated successfully, but these errors were encountered: