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/j...)
extending official Testcontainers BrowserContainer
(
https://github.com/testcontainers/testcontainers-java/blob/master/modules...),
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?
Thanks!