@timbmg, thank you for the suggestion. My hunch is that the scope of the library would start ballooning a bit if we start introducing build steps. Having said that, you raise a good point that it's available for docker-compose if #78 is merged.

Is there any reason why running docker build prior to spinning up your tests isn't sufficient or desirable?

I can't really imagine a workflow where this could be useful.

Surely the other dependencies will be built beforehand, and if they're not then docker-compose will build them.

Was just looking for exactly this feature - I would like to be able to start a database container, but I need it to have some additional extensions to be installed first.

The beauty of test containers is that I don't need to build anything else prior to starting my tests - I start them and it just works. But if this is not supported then I have to come up with some fixture that does that for me, perhaps using the provided docker client.

@tillahoffmann This appears to be supported in Java.
Let's reconsider this feature.

+1 :)

@tillahoffmann
+1

I have a use case where I would like to use Dockerfile.

I'm ready to contribute and implement the feature if possible

I han API designed with FastAPI and I would like to leverage the power of testcontainers to test the build and readiness of my API

My tests would look like :

def test_docker_run_with_dockerfile():
    fastapi_container = FastAPIContainer("fastapi:local", dockerfile="/workspace/my-api/", port=8000)
    with fastapi_container as fastapi:
        url = f"http://{fastapi.get_container_host_ip()}:{fastapi.get_exposed_port(fastapi.port)}/"
        r = requests.get(url)
        logging.info(r.text)
        assert r.status_code == 200
        assert "Welcome to fastapi with dockerfile!" in r.text

i dont know where it would fall on our list of priorities but i think it would be acceptable for this library to have something like:

https://github.com/testcontainers/testcontainers-java/blob/d3b0df2d89ee349890c94b0ce220a167c82ddf51/core/src/test/java/org/testcontainers/junit/DockerfileTest.java#L54-L71

    @Test
    public void dockerfileBuilderWorks() {
        ImageFromDockerfile image = new ImageFromDockerfile()
            .withFileFromClasspath("test.txt", "mappable-resource/test-resource.txt")
            .withFileFromString("folder/someFile.txt", "hello")
            .withDockerfileFromBuilder(builder -> {
                builder
                    .from("alpine:3.16")
                    .workDir("/app")
                    .add("test.txt", "test file.txt")
                    .run("ls", "-la", "/app/test file.txt")
                    .copy("folder/someFile.txt", "/someFile.txt")
                    .expose(80, 8080)
                    .cmd("while true; do cat /someFile.txt | nc -l -p 80; done");
            });

        verifyImage(image);
    }

Hello!
Can I be assigned to this one please?
I woule like to implement it if it's okay for you.
Thanks!

the potential implementation in #455 is very interesting but id like to figure out how we can do this without passing image and dockerfile separately. whereas the reference implementation from java uses a DockerImage class, we can have a Union type of DockerImage (or some other name) and str - where that other type would provide an os.PathLike and an indication that it should be build with the docker client.

ill assign the issue to you for now but I think we are generally looking for feedback from any potential users or contributors about a better API design (or testing ideas).

I totally agree with you. I also had a thought about another way to implement it using a specific class for image building without changing the docker client class. I'm even more confortable with it!

I'll propose you changes with another way of doing that.

Hello @alexanderankin!
Just to let you know that I updated the PR with my new proposal. I'm open to any feedback and of course changes requests if you have.
Thanks

@alexanderankin you asked for some feedback and alternative API design, I hope you will find #559 Interesting.
I think keeping it more like the original DockerContainer is the way to go, Context manager is more pythonic and this version helps to keep it more separated.

I was in the middle of job switching when i was added as contributor, the new job has really kicked up a notch and I haven't had time to spend on testcontainers all that much. to be clear, this issue is not a priority for the project. It is at least below fixing DinD, MacOS/Windows, and ipv6/ipv4 stuff, things that prevent people using the library. i re-opened this as a nice to have, not a core requirement. hope to be able to revisit soon.