test(grails-data-hibernate7): re-enable Oracle in the RLikeHibernate7Spec dialect matrix - #16027
test(grails-data-hibernate7): re-enable Oracle in the RLikeHibernate7Spec dialect matrix#16027borinquenkid wants to merge 1 commit into
Conversation
…Spec dialect matrix Oracle Testcontainers has historically been flaky enough in CI that this row was disabled. Re-evaluating now: gvenzl/oracle-free:slim-faststart ships native ARM64 + x86_64 images (no more x86-under-emulation startup penalty on Apple Silicon), and ran to "DATABASE IS READY TO USE!" in ~13s locally on repeated runs. Adds an explicit 3-minute startup timeout as a safety margin against the known too-tight default (testcontainers/testcontainers-java#9057) without slowing down the common case. This is test-only, no production code changes - if Oracle proves flaky again in real CI (particularly on shared/loaded runners, which this local run can't represent), the row can be dropped again. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
This PR re-enables the Oracle row in the Testcontainers-backed dialect matrix for RLikeHibernate7Spec, with an explicit startup timeout to reduce historical Oracle container flakiness on slower CI runners.
Changes:
- Add an explicit
withStartupTimeout(Duration.ofMinutes(3))to the Oracle Testcontainers configuration. - Re-enable the
"Oracle" | oracleentry in thewhere:matrix so the same RLIKE assertion runs against Oracle. - Add
java.time.Durationimport and inline rationale comment documenting the timeout choice.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## 8.0.x #16027 +/- ##
==================================================
- Coverage 51.4517% 51.4507% -0.0010%
+ Complexity 17733 17731 -2
==================================================
Files 2039 2039
Lines 95507 95507
Branches 16564 16564
==================================================
- Hits 49140 49139 -1
Misses 39067 39067
- Partials 7300 7301 +1 🚀 New features to boost your workflow:
|
✅ All tests passed ✅🏷️ Commit: 8d92089 Learn more about TestLens at testlens.app. |
|
The oracle images have extreme license restrictions so we need to talk to people on this one. I suspect the weekly is best for this one. |
|
|
FYI: this has been previously discussed when distributing the oracle jdbc drivers came up (https://lists.apache.org/thread/806jtj39zfbz07wfmz545mk6lrl2x8wc). It was deemed a category X license at that time. I think this might be ok since we're only using it in test and not distribution though. This is just something we need to make sure there's agreement on in the weekly. We may want to specifically consult with @paulk-asert on this too. |
|
I also want to point out that we need to look at this docker image - how often is it patched? etc. We need to ensure it's not a security risk for the project (and thus the build agents / ci) |
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-faststartnow ships native ARM64 + x86_64 images (no more x86-under-emulation startup penalty), and reportedDATABASE IS READY TO USE!in ~13s across repeated local runs (Docker Desktop, Apple Silicon).withStartupTimeout(Duration.ofMinutes(3))as a safety margin against the known too-tight 60s default ([Bug]: Timed out waiting for log output matching '.*DATABASE IS READY TO USE!.*\s' testcontainers/testcontainers-java#9057), which has caused flakiness on loaded/slower CI runners historically."Oracle" | oraclerow in thewhere: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-latestrunners (shared, resource-constrained, where the original flakiness reports concentrated) or Windows runners. This repo'sisDockerAvailable()check means the whole Testcontainers matrix already no-ops on Windows/macOS GitHub-hosted runners today, soubuntu-latestin 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
RLikeHibernate7Speclocally against real Testcontainers-launched Postgres, MySQL, MariaDB, and Oracle - all 5 dialect rows (H2 included) pass.codeStyle(checkstyle + CodeNarc): clean.ubuntu-latestCI runners across multiple runs - this is what should determine whether to merge or close this PR.Co-Authored-By: Claude Sonnet 5 noreply@anthropic.com