borinquenkid commented on code in PR #16066:
URL: https://github.com/apache/grails-core/pull/16066#discussion_r3804122842


##########
gradle/test-config.gradle:
##########
@@ -33,6 +33,38 @@ dependencies {
     add('testRuntimeOnly', 'org.objenesis:objenesis')
 }
 
+/**
+ * Recursively checks if a project has a direct or transitive dependency on a 
target project.
+ * Used to detect modules that rely on GORM (grails-datamapping-core), which 
are prone to
+ * cross-test registry pollution when executed in parallel (maxParallelForks > 
1).
+ *
+ * Uses Gradle 9 compatible path lookup (proj.project(pd.getPath())) because
+ * ProjectDependency.getDependencyProject() was removed in Gradle 9.
+ *
+ * @param proj the project to inspect
+ * @param targetProjectName the name of the target dependency project (e.g. 
'grails-datamapping-core')
+ * @param visited set of already visited projects to prevent infinite 
recursion in cyclic dependency configurations
+ * @return true if the project depends on the target project
+ */
[email protected]

Review Comment:
   Moot now — removed `dependsOnProject` entirely along with the 
`isGormProject` gate it fed. See the general comment below for why.



##########
gradle/test-config.gradle:
##########
@@ -83,7 +115,11 @@ tasks.withType(Test).configureEach {
         showStackTraces = true
     }
     excludes = ['**/*TestCase.class', '**/*$*.class']
-    maxParallelForks = configuredTestParallel
+    
+    // Selectively isolate GORM (grails-datamapping-core) dependent tests to 
prevent GormRegistry conflicts
+    def isGormProject = dependsOnProject(project, 'grails-datamapping-core')

Review Comment:
   You were right to push on this. Verified empirically rather than just 
arguing it: ran a full CI pass with the isolation removed — 
`configuredTestParallel` forks for `grails-datamapping-core` and every 
GORM-dependent module, all running concurrently on the same shared 
`macos-latest` runner this PR's CI already uses — and it passed clean, 
including `GormRegistryConcurrencySpec` under real concurrent-fork load. Each 
Gradle fork is an independent JVM with its own `GormRegistry` singleton 
instance; there's no shared heap between forks, so there was never a genuine 
cross-fork data hazard here. Removed the whole mechanism in 9e3e06ddf4.
   
   Run: https://github.com/apache/grails-core/actions/runs/32087151762



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