jdaugherty opened a new pull request, #16626: URL: https://github.com/apache/grails-core/pull/16626
`ContainerGebSpec` now starts `selenium/standalone-chromium` instead of `selenium/standalone-chrome`, and `containerBrowser = 'chromium'` works in `GebConfig.groovy`. ### Why The default Geb functional test that Forge generates fails out of the box on Apple silicon under Docker Desktop. `WebDriverContainerHolder` always passes an explicit image, `selenium/standalone-<browser>:<Selenium version on the classpath>`, so Testcontainers' own aarch64 fallback never runs. With Selenium 4.43.0 on 8.0.x that is `selenium/standalone-chrome:4.43.0`, and that tag only has a `linux/amd64` manifest. Docker Desktop's Docker VMM backend emulates amd64 with QEMU, and Chrome dies as soon as the test connects: ``` NoSuchSessionException: session deleted as the browser has closed the connection ``` Docker Hub manifests, checked 2026-10-12 with `docker buildx imagetools inspect`: | Image | 4.43.0 | first tag with arm64 | |---|---|---| | `selenium/standalone-chrome` | amd64 only | 4.47.0 | | `selenium/standalone-chromium` | amd64 + arm64 | already multi-arch | | `selenium/standalone-firefox` | amd64 + arm64 | already multi-arch | So the breakage follows whatever Selenium version the Spring Boot BOM resolves, and would have reappeared on every branch below 4.47.0. ### History - Ken Kousen's Grails 8 workshop repository, [kousen/holygrails8](https://github.com/kousen/holygrails8), hit this on 6 Oct while building the labs (commit `8c688ce`). The first fix was a Firefox `GebConfig.groovy` plus `selenium-firefox-driver`. The lab notes that Chromium also has an arm64 image, "but Testcontainers rejects it as an unknown substitute for the Chrome image, so Firefox is the one-line answer." - Later that day (commit `b45c994`) he verified the stock Chrome image passes once Docker Desktop is switched to the Apple Virtualization framework with Rosetta, and recorded the Docker VMM / QEMU cause. The repository kept the Firefox config because it works on every Docker setup. - The talk's closing list names a grails-geb issue to file: "accept the Chromium image as a Chrome substitute, or default to a multi-arch image on arm64 hosts". This PR does both, unconditionally, because Chromium is multi-arch everywhere and there is no reason to prefer the amd64-only image on amd64 either. - The rejection is `BrowserWebDriverContainer` calling `DockerImageName.assertCompatibleWith` against the Chrome, Firefox and Edge images only (verified in Testcontainers 1.21.4 and 2.0.5). `asCompatibleSubstituteFor("selenium/standalone-chrome")` is the supported way to declare another image acceptable; both images bundle `chromedriver` and take the same `ChromeOptions`, which the default driver already uses. - The problem does not reproduce on OrbStack, which runs amd64 images under Rosetta by default, which is why our own arm64 runs never saw it. ### Changes - `WebDriverContainerHolder`: default browser is `chromium`; any `chromium` image, including one resolved from the `grails.geb.container.image.template` system property, is registered as a Chrome substitute. `chrome`, `firefox` and `edge` are unchanged. - `WebDriverContainerHolderSpec`: covers the default image and its substitute registration (including that Testcontainers accepts it for a `BrowserWebDriverContainer`), the untouched browsers, and the image template. - grails-geb README: new "Browser Container Image" section documenting the default, the arm64 reason, and the previously undocumented `grails.geb.container.image.template` property; `chromium` added to the `containerBrowser` list. - Functional testing guide: notes the multi-arch default image and where to change it. ### Verification - `:grails-geb:test --tests WebDriverContainerHolderSpec` and `:grails-geb:codeStyle`. - `:grails-test-examples-test-phases:functionalTest` on an Apple silicon host, which pulled `selenium/standalone-chromium:4.43.0` for `linux/arm64` and passed. CI covers the same spec and the other `ContainerGebSpec` examples on amd64. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
