Improve Groovy Joint Validation Build CI stability#15484
Merged
jdaugherty merged 1 commit into7.0.xfrom Mar 4, 2026
Merged
Conversation
Add --continue so a single flaky test failure does not abort the entire 45-minute build. Add --stacktrace for better failure diagnostics (matching the main CI workflow). Reduce maxTestParallel from 4 to 2 to lower memory pressure - the joint build runs all tests (unit, integration, functional, MongoDB) in a single job alongside the Gradle daemon (5G) and MongoDB container on a 7GB runner. Assisted-by: Claude Code <Claude@Claude.ai>
47fbfb5 to
7ea2132
Compare
Contributor
There was a problem hiding this comment.
Pull request overview
Improves the stability and debuggability of the Groovy Joint Validation Build CI workflow by adjusting Gradle invocation flags to better tolerate flaky tests and reduce resource pressure on GitHub-hosted runners.
Changes:
- Add Gradle
--continueso the job reports all failures in one run instead of aborting on the first failure. - Add Gradle
--stacktraceto improve failure diagnostics. - Reduce test parallelism via
-PmaxTestParallel=3to lower memory pressure.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
jdaugherty
approved these changes
Mar 4, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
--continueso a single flaky test failure does not abort the entire ~45-minute Groovy Joint build (the job still fails at the end - it just reports all failures in one run)--stacktracefor better failure diagnostics (matching the main CI workflow)maxTestParallelfrom 4 to 3 to lower memory pressure on CI runnersProblem
Analysis of the last 80 Groovy Joint Validation Build runs shows 16 failures (20% failure rate) with these recurring patterns:
AsyncPromiseSpec > async service processes string input(ReadTimeoutException)UserControllerSpec > User list(scaffolding Geb flaky login)DefaultServiceRegistrySpec(ServiceConfigurationError)WhereQueryOldIssueVerificationSpec(flaky hibernate5 test)MicronautErsatzRoundtripSpec(flaky Ersatz mock)The Groovy Joint workflow is uniquely vulnerable because it runs all tests (unit + integration + functional + MongoDB) in a single job. Without
--continue, one flaky test kills the entire build. The JVM crash occurred because 4 parallel test forks (each 768m) + Gradle daemon (5G) + MongoDB container exceeds the ~7GB runner memory.Changes
groovy-joint-workflow.yml:--continue: Lets the build finish and report all failures instead of aborting on the first one. The job still exits non-zero so CI stays red.--stacktrace: Provides full stack traces on failure (the main CI workflow already uses this)-PmaxTestParallel=3: Reduces parallel test forks from 4 to 3, cutting test JVM memory usage from ~3GB to ~2.3GB. This gives more headroom for the Gradle daemon and MongoDB container on the ~7GB GitHub runner.