Automatically substitute selenium docker images by seleniarm ones when on ARM64

[vmassol]

It seems that the selenium team won't support ARM64 for selenium according to https://github.com/SeleniumHQ/docker-selenium#experimental-mult-arch-aarch64armhfamd64-images. Instead they provide seleniarm images and they don't seem to intend to merge them.

Thus, it would be nice if TC could make it simpler to developers and do the substitution work automatically.

FTR this is what I had to write:

        BrowserWebDriverContainer<?> webDriverContainer = new BrowserWebDriverContainer<>(isARM64()
            ? DockerImageName.parse(getSeleniarmImageName()).asCompatibleSubstituteFor(getSeleniumImageName())
            : DockerImageName.parse(getSeleniumImageName()))
            .withCapabilities(browser.getCapabilities())
...
    private String getSeleniarmImageName()
    {
         return CHROME.equals(this.testConfiguration.getBrowser())
            ? "seleniarm/standalone-chromium" : "seleniarm/standalone-firefox";
    }

    private String getSeleniumImageName()
    {
        return CHROME.equals(this.testConfiguration.getBrowser())
            ? "selenium/standalone-chrome" : "selenium/standalone-firefox";
    }

    private boolean isARM64()
    {
        return System.getProperty("os.arch").equals("aarch64");
    }

Thanks!

[deejgregor]

I'm happy to submit a PR for this issue doing something like @vmassol's example. I'm also happy to take guidance to aim a different way if you prefer.

I've opened https://github.com/seleniumhq-community/docker-seleniarm/issues/26 with Seleniarm to see if they can publish their Docker containers with tags that are just the Selenium version number. If we can get both of these two issues in, then we can make the testcontainers Selenium support work out of the box again on recent Macs, which would be really nice.

[eddumelendez]

Hi, we have discussed this internally and we think there are a few reasons why not having this on testcontainers.

1. As selenium mentioned this is still experimental
2. We can not make sure these images are working on CI
3. We think this should be fixed on selenium side

Our conclusion, is to provide documentation about it by implementing their own custom function. So, people interested can do it by themselves.

Of course, contribution are welcome.

[deejgregor]

@eddumelendez Thanks for the detailed response. I’ll talk to the Selenium/Seleniarm folks.

If it looks like this can’t be addressed soon by them, would you be open to the possibility of adding an opt-in configuration flag (like exists for the image name substitution) to substitute in the Seleniarm images and/or adding a check to make BrowserWebDriverContainer fail (or at least warn like this does and point to docs) if the container is running under emulation (maybe with opt-out flag to disable this check)? Right now BrowserWebDriverContainer is completely non-functional under emulation (at least in my experience), and the failure does not give any clear indications about why or how to fix it, so I’d like to try to make this better one way or another (ideally upstream, but we’ll see).

[eddumelendez]

I think that once the PR adding the warning about using images with different arch is merged then it will cover it. Do you suggest to add an extra warning for selenium?

I totally understand your need but the BrowserWebDriverContainer is already quite complex and we would like to avoid to introduce even more of it in there. However, we would like to cover it with docs. If Selenium team doesn't feel comfortable making this part of the official image there should be a reason and as I mentioned before, there would be lack of test on CI for this new image. Of course, we can test it locally but it's not efficient.

[deejgregor]

I realized one easy thing that would help along with the warning is adding the Seleniarm images to the compatible list so you can avoid the extra work needed for the image substitutor. I think and docs would cover it okay.

[eddumelendez]

Adding it to the compatible list and remove it later will bring a breaking change. Also, adding it to the compatible list means it has been tested on testcontainers side and that's why it is being promoted when indeed it is not something we want to do. That's why the suggestion is to add docs.

[eddumelendez]

I think there is no much to do here due to the experimental images.