testcontainers-dotnet: Can't create docker image for dotnet web api project

I will close this issue, because it contains all kinds of information to set up the configuration properly. @Omrisha this might be interesting for you as well: https://github.com/testcontainers/testcontainers-dotnet/issues/610#issuecomment-1299996820. Depending on your Dockerfile this might work:

_ = new ImageFromDockerfileBuilder()
  .WithDockerfileDirectory("C:/Repos/Microservices")
  .WithDockerfile("Applications/AuthorizationServer/Application/WebApiApplication/Dockerfile")
  .Build();

Thanks to everyone. Due to your various configurations, we were able to add some more improvements to the builder. Version 2.2.0 as well as the next release are not that strict anymore regarding path conventions etc.

If you still struggle, to set it up, please do not hesitate to reopen the issue again.

I found that trailing /s in .dockerignore cause all files to get ignored.

That is fixed with #604.

In my case, my Dockerfile lives at myrepo/src/common/dotnet/Dockerfile And the build context is expected to be myrepo/src

Testcontainters for .NET creates a tarball of the content of WithDockerfileDirectory and passes the tarball to Docker. This tarball is the “new” root of the Dockerfile and must contain all files, etc.

Your configuration above looks good. The Dockerfile is inside the WithDockerfileDirectory directory tree. Does it still not work?

I feel like this issue would be pretty easy to solve if there was any inkling of an error message.

Docker.Dotnet does not forward the error. The issue has been fixed recently with https://github.com/dotnet/Docker.DotNet/pull/590, but there is no new release yet. But I agree, we need to improve the developer experience here, it looks like the current implementation or behavior is too complicated.

Does that help?

You exclude your own Dockerfile.

I have effectively not may enough attention on the path you give me, my mistake. Thank you.

C:.
│
└───GitHub-Issue-610
    └───src
            foo.txt
            WeatherForecastDockerfile

Builder configuration

_ = new ImageFromDockerfileBuilder()
  .WithDockerfileDirectory("C:/GitHub-Issue-610")
  .WithDockerfile("src/WeatherForecastDockerfile")
  .Build();

WeatherForecastDockerfile

FROM alpine:3.14
COPY src/foo.txt /tmp/

Alright best I can tell, my .yarn/* entry in my dockerfile was getting turned into the pattern ^([\\\/]?(([^\\\/]+)?$\b|$)) which matched Directory.Packages.props. Switched it to .yarn and all is well.

The logging was because I wasn’t setting the logger early enough in the process. I was building the image in a fixture, but trying to use ITestOutputHelper which doesn’t seem like you can get access to in fixtures.

I currently have the same problem. After quite a bit of debugging, I found that trailing /s in .dockerignore cause all files to get ignored. Docker doesn’t care, but the ignore logic in this lib will turn them into regex’s that match all files, and thus ignore all files. For example, **/bin/ vs **/bin. Something to check at the very least.

For me, after fixing that it still fails to build the image. Does WithDockerfileDirectory correspond to the build context? Should WithDockerfile be relative to the path given in WithDockerfileDirectory?

In my case, my Dockerfile lives at myrepo/src/common/dotnet/Dockerfile And the build context is expected to be myrepo/src To build the image, I’m using

await new ImageFromDockerfileBuilder()
    .WithName(BaseImage)
    .WithDockerfile(Path.Combine("common", "dotnet", "Dockerfile"))
    .WithDockerfileDirectory(CommonDirectoryPath.GetGitDirectory(), "src")
    .Build()

I feel like this issue would be pretty easy to solve if there was any inkling of an error message. I tried debugging into the internal Docker.Dotnet calls to see if I could pull anything from the log steam it seems to be using, but either my debugging skills are lacking or there’s nothing there.

I also tried setting up an XUnit ITestOutputHelper and passing that to Testcontainers, but since the error seems to be happening with Docker.Dotnet that didn’t lead to much.