borinquenkid opened a new pull request, #16027:
URL: https://github.com/apache/grails-core/pull/16027

   ## Summary
   
   Aspirational/experimental: re-enables the Oracle row in 
`RLikeHibernate7Spec`'s Testcontainers-backed dialect matrix, which was 
previously disabled due to known flakiness in Oracle's Testcontainers image.
   
   **No production code changes** - this is test-config only:
   
   - `gvenzl/oracle-free:slim-faststart` now ships native ARM64 + x86_64 images 
(no more x86-under-emulation startup penalty), and reported `DATABASE IS READY 
TO USE!` in ~13s across repeated local runs (Docker Desktop, Apple Silicon).
   - Added an explicit `withStartupTimeout(Duration.ofMinutes(3))` as a safety 
margin against the known too-tight 60s default 
(testcontainers/testcontainers-java#9057), which has caused flakiness on 
loaded/slower CI runners historically.
   - Un-commented the `"Oracle" | oracle` row in the `where:` table, so it now 
runs the same functional RLIKE-query assertion the other four dialects already 
run.
   
   **Why this might still not be safe to keep:** my local verification is Apple 
Silicon with Docker Desktop and a warm image cache - it doesn't represent 
GitHub Actions' `ubuntu-latest` runners (shared, resource-constrained, where 
the original flakiness reports concentrated) or Windows runners. This repo's 
`isDockerAvailable()` check means the whole Testcontainers matrix already 
no-ops on Windows/macOS GitHub-hosted runners today, so `ubuntu-latest` in CI 
is the real test here, not this PR description.
   
   If Oracle proves flaky again on real CI, the row is a one-line revert.
   
   ## Test plan
   
   - [x] Ran `RLikeHibernate7Spec` locally against real Testcontainers-launched 
Postgres, MySQL, MariaDB, and Oracle - all 5 dialect rows (H2 included) pass.
   - [x] Repeated the run a second time to check for obvious flakiness - 
consistent pass, ~13-15s Oracle startup both times.
   - [x] `codeStyle` (checkstyle + CodeNarc): clean.
   - [ ] Real signal on `ubuntu-latest` CI runners across multiple runs - this 
is what should determine whether to merge or close this PR.
   
   Co-Authored-By: Claude Sonnet 5 <[email protected]>


-- 
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]

Reply via email to