testcontainers
[Feature] Add tty option
Thanks for branching this wonderful project out into the Rust space!
Some images rely on a tty being available to properly function. This should cover it!
Can you provide an example docker image that requires docker to have a pseudo-tty configured? So this can be verified. I am not 100% sure this works with stdout piped https://github.com/testcontainers/testcontainers-rs/blob/dev/testcontainers/src/clients/cli.rs#L188 this is why i ask
I can't quite reproduce the image (some php + openrc stuff) I was working with but essentially it looked like the snippet below, symlinking from the tty over to the log locations and expecting /dev/pts/0 to be writable.
Example
FROM nginx:stable-alpine
COPY init.sh /
RUN ln -nsf /dev/pts/1 /var/log/nginx/access.log
ENTRYPOINT ["/init.sh"]
init.sh
chmod o+w /dev/pts/1
I tested my changes with the image and confirmed that running with -it allows the container to boot.
Thanks! Maintaining a minimal API is something that is really important, hence a couple of questions:
- Would it hurt to always try and allocate a tty and not expose this config option at all?
- The option seems to be image specific so I think we can remove the override on
RunnableImage? - It would be nice to add a test-case with an actual docker image for such purposes. You can add them here so they are available within the test-suite!
Hi @thomaseizinger!
Thanks for putting this thing together!
I actually do agree that having ptty available is a sensible default. If I flip the bit in the trait default implementation the implementing party will not be required to override it while leaving the the option there if they specifically want to not allocate a ptty. What do you think?
I added a test case too as per request 👍
:v: ASAPHAANING can now approve this pull request. To approve and merge a pull request, simply reply with bors r+. More detailed instructions are available here.
![bors[bot] avatar](https://avatars.githubusercontent.com/in/1847?v=4 "Published by a pub.dev verified publisher"){kind=small}
bors retry
I think the test_ipv4_ipv6_host_ports test is broken on dev.
I can make the entire suite run if I comment out the ipv6 assertions.
bors retry
I think the
test_ipv4_ipv6_host_portstest is broken ondev. I can make the entire suite run if I comment out the ipv6 assertions.
Damn. Thanks for investigating. I'll see to look into this in more detail but it will be a while as I am traveling for the next two weeks.
