Hello!
First of all, thanks for the effort Harald! It is true, we've been experimenting with running old testsuite against containers, but I think we've used containerisation of the WildFly server only, mostly to simplify automatisation of the server preparation. Having the containers being taken care of automatically by a solid Java API and placing it in the testsuite is a great idea. In addition to that, having containerised Selenium+Browser is also a great step forward. I wonder if that would stabilise the browser issues we're currently having with the current testsuite.
IIRC Testcontainers should have the Podman/Docker daemon path configurable, which should work out the images download/preparation issues mentioned earlier, and we could implement this into a prepare CI job.
When trying to run Manatoko on our CI, I've hit Docker pull limit being exceeded. This is linked to the Browser container (https://github.com/hpehl/manatoko/blob/main/container/src/main/java/org/jboss/hal/testsuite/container/Browser.java#L31) extending official Testcontainers BrowserContainer (https://github.com/testcontainers/testcontainers-java/blob/master/modules/selenium/src/main/java/org/testcontainers/containers/BrowserWebDriverContainer.java#L49), which uses Docker Hub for pulling images. Could this be changed to use Selenium Standalone Images hosted on Quay? I've noticed there is already Red Hat Quay repository for Selenium standalone images, see https://quay.io/repository/redhatqe/selenium-standalone.
Last question would be, whether Manatoko could be changed to have necessary containers parameterised? Or what is your idea on how the images will be prepared and by whom?