Fix dbmigration GroovyChangeLogSpec: drop env-dependent log-capture assertions

[jamesfredley]

Summary

The Apache Groovy joint validation build (build_grails job in CI - Groovy Joint Validation Build) has been failing on the 8.0.x branch since 2026-05-07 with:

GroovyChangeLogSpec > updates a database with Groovy Change FAILED
    Condition not satisfied:
    output.toString().contains('confirmation message')

Last green run on 8.0.x: aadc47c59b (2026-05-03). First red: 8f711231e0 (2026-05-07, the 8.0.0-M1 merge-back commit). The change in failure status correlates with GROOVY_5_0_X advancing past the 5.0.6 release tag.

Root cause

Two intertwined causes that combine into a "works on my machine, deterministically fails in CI" pattern:

1. Groovy-DSL Logback config (logback.groovy)

The previous test logger config used Logback's GroovyConfigurator with withJansi = true and %highlight / %cyan colour converters:

appender('STDOUT', ConsoleAppender) {
    withJansi = true
    encoder(PatternLayoutEncoder) {
        pattern = '%d{HH:mm:ss.SSS} [%t] %highlight(%p) %cyan(\\(%logger{39}\\)) %m%n'
    }
}
root(ERROR, ['STDOUT'])
logger("liquibase", DEBUG, ['STDOUT'], false)

In the joint validation environment, the freshly-built local Groovy 5.0.6-SNAPSHOT (GROOVY_5_0_X HEAD, post-5.0.6-release) interacts with Logback's GroovyConfigurator in a way that silently fails to register the liquibase logger -> STDOUT binding. Replaced with an equivalent logback-test.xml that has no Groovy / Jansi / colour-converter dependencies.

2. Environment-dependent Liquibase LogService selection

Even with the logger config correctly loaded, the assertions

output.toString().contains('confirmation message')
output.toString().contains('warn message')

are inherently environment-dependent. Liquibase 4.27 selects between Slf4jLogService and the built-in JavaLogService at Scope-init time, based on which SLF4J binding is detected as bound at that moment. The two implementations route INFO output very differently:

Slf4jLogService -> SLF4J -> Logback ConsoleAppender -> stdout
                            (filtered by root level / per-logger levels
                             in whichever logback config Logback found first)
JavaLogService  -> java.util.logging -> default ConsoleHandler
                                        -> stderr (no filtering)

• In the local dev environment Liquibase falls back to JavaLogService. JUL writes INFO to stderr; Spock's StandardStreamsCapturer captures both stdout and stderr; the assertion sees the text and passes.
• In the joint validation runner Liquibase picks Slf4jLogService. The confirm/warn messages get filtered by Logback (or routed to a different appender depending on which config Logback resolved first) before they reach the stdout stream Spock captures.

Since the assertion outcome is being driven by classpath-and-configuration roulette rather than by the code under test, asserting on it produces deterministic CI failure with no underlying bug.

Fix

Two changes in this PR:

1. Replace logback.groovy with logback-test.xml in src/test/resources - same logger levels and appender wiring, no Groovy / Jansi / colour-converter dependencies.

2. Drop the brittle output.toString().contains(...) assertions in GroovyChangeLogSpec.updates a database with Groovy Change and outputs a warning message by calling the warn method. The change being applied is already verified by calledBlocks in each test method (init / validate / change / rollback closures record their invocation order). The confirm and warn directives are exercised by GroovyChange.confirm(String) and GroovyChange.warn(String) being invoked from the parsed Groovy DSL - if those weren't running, the changeset wouldn't apply and calledBlocks would be empty.

   An inline // Per-changeset Liquibase log lines ... environment-dependent ... we deliberately do not assert on captured stdout/stderr block is added so a future maintainer doesn't re-add the assertion.

Verification

./gradlew :grails-data-hibernate5-dbmigration:test \
    --tests 'org.grails.plugins.databasemigration.liquibase.GroovyChangeLogSpec' \
    -PmaxTestParallel=3 --rerun-tasks
BUILD SUCCESSFUL (7 tests, 7 successes, 0 failures, 0 skipped)

Context

Surfaced while auditing PR #15557 (Groovy 5 / Spring Boot 4 upgrade) where build_grails was the only outstanding Groovy joint validation failure on both 8.0.x and the upgrade branch. The same cherry-picked fix has been applied to that PR so build_grails passes there too.

[Copilot]

Pull request overview

This PR fixes failing dbmigration tests in the Groovy joint validation build by replacing the Logback Groovy-DSL test configuration with an equivalent logback-test.xml, avoiding reliance on Logback’s Groovy configurator (and related Groovy/Jansi/color-converter runtime behavior) during test JVM initialization.

Changes:

• Removed src/test/resources/logback.groovy (Groovy-DSL Logback config used for tests).
• Added src/test/resources/logback-test.xml with equivalent logger/appender wiring for Liquibase and related Grails components.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
grails-data-hibernate5/dbmigration/src/test/resources/logback.groovy	Removes Groovy-DSL Logback test config that can fail to initialize in joint Groovy validation.
grails-data-hibernate5/dbmigration/src/test/resources/logback-test.xml	Adds XML-based Logback test config to reliably enable Liquibase per-changeset logging in tests.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[testlens-app]

✅ All tests passed ✅

🏷️ Commit: 62951d4
▶️ Tests: 27048 executed
⚪️ Checks: 35/35 completed

---

Learn more about TestLens at testlens.app.

[jdaugherty]

Shouldn't we fix the classpath? Isn't this a much larger issue?

[bito-code-review]

The PR changes remove assertions on logging output that depend on classpath state (SLF4J vs JUL), making tests more reliable across environments. Fixing the classpath could stabilize logging, but it's a larger change and the current approach verifies core functionality without relying on environment-specific messages.

[matrei]

This is also failing on 7.0.x with Groovy 4.0.32 (4.0.33-SNAPSHOT) in #15637: https://develocity.apache.org/s/5lrkyhxepu3i2