Repository navigation
Conversation
- Revert build.yml timeout from 90 to 120 minutes; 90 was too tight given the MySQL lane alone measures ~69 min locally with no margin. - Rename the coreH2Test/coreMySQLTest/corePostgreSQLTest inputs.property key from includeDockerTaggedTests to coreTestIncludesDockerTaggedTests, distinguishing it from the unrelated extensions.extraProperties[includeDockerTaggedTests] flag consumed by root build.gradle.kts's shared test setup. - Drop the hardcoded "()" from BackendTestExtension's getDisplayName(): @testtemplate methods can declare real parameters, so an empty parameter list misrepresented the method's signature in JUnit XML/HTML reports. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015k3E9XykKTzbTWaBPwqTyE
…+ BackendLaneCondition The three excludeTags(otherTwoBackends) clauses in registerCoreTestTask allowed two silent failure modes with no build-time check: a class carrying two backend tags was excluded from every lane, and a class missing its restriction tag ran redundantly in all three. Replace them with a single typed source of truth: - DatabaseBackend: the three core database backends. - DatabaseTest: annotation declaring backends() (defaults to all three), meta- annotated with the lane-inclusion tag and @ExtendWith(BackendLaneCondition). - BackendLaneCondition: an ExecutionCondition that reads the lane's gravitino.core.test.backend system property (already published by registerCoreTestTask) and enables/disables the class accordingly, producing a visible, reported skip rather than silent exclusion from Gradle's discovery. - TestDatabaseTestClassification: a build-time reflection check (runs in coreUnitTest, no database, no Docker) asserting no @databasetest(backends={}) and no leftover raw per-backend @tag usages anywhere in core. core/build.gradle.kts's three-way excludeTags table collapses to a single includeTags(coreDatabaseTestTag); backend restriction now lives entirely in test source. Migrated all three existing usage patterns: AbstractEntityStorageTest (parameter-driven multi-backend via storageProvider()/BackendTestSelector), TestJDBCBackend (@TestTemplate-driven via BackendTestExtension), and TestJdbcPartitionStatisticStorageIT's three single-backend @nested classes. Verified via TestBackendLaneCondition (direct unit coverage) and a real :core:coreH2Test run before/after the change: identical 520 executed tests and outcomes: the only delta is 2 classes (14 tests) that were previously excluded from Gradle's own discovery and now appear as an explicit, reported skip. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015k3E9XykKTzbTWaBPwqTyE
…abasetest + BackendLaneCondition" This reverts commit efee6a4.
… change 654cfe3 dropped the hardcoded "()" from BackendTestExtension's getDisplayName() but didn't update this test's assertions, leaving coreUnitTest red on this branch. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015k3E9XykKTzbTWaBPwqTyE
compare_legacy_partition() (and its "compare-legacy" CLI subcommand) compared a legacy :core:test manifest against the union of the four split-lane manifests, but nothing in .github/workflows/build.yml ever called it - dev/ci/test-shards.sh excludes :core:test from CI entirely, so no legacy manifest is ever produced to compare against. manifest and reconcile, which ARE CI-wired, are untouched. Removes the dead function, its argparse subcommand, its dedicated unit tests, and the legacy/ fixture directory only they consumed. Drops the now-unused "legacy" choice from MANIFEST_LANES. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015k3E9XykKTzbTWaBPwqTyE
The three excludeTags(otherTwoBackends) clauses in registerCoreTestTask excluded a class from every lane if it carried two conflicting backend tags, instead of running it under each tagged backend. Replace the hand-written per-backend cases with one JUnit boolean tag expression built from a backend->tag map: exclude a class only when it is pinned to another backend and not to this one. A class tagged for several backends now runs under each of them; adding a backend is one map entry. Still a discovery-time PostDiscoveryFilter (same as the tags it replaces), so an excluded class never appears in a lane's JUnit XML - core_test_identity.py's foreign-backend-marker check, which is wired into CI, still sees exactly what it did before. Verified against a real :core:coreH2Test run: reproduced the original bug on the old scheme (a double-tagged class silently excluded from every lane), then confirmed the fix runs it correctly with a clean, single-class XML directory and a passing manifest step. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015k3E9XykKTzbTWaBPwqTyE
The previous commit unintentionally bundled in a restore of this file to its pre-compare-legacy-removal state (2 failing tests, referencing functions and fixtures bed4a93 already removed) alongside the unrelated core/build.gradle.kts fix. Not the intended change; reverting to bed4a93's version. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015k3E9XykKTzbTWaBPwqTyE
…er tag The gatekeeper+modifier scheme (gravitino-core-database-test required for any DB lane, plus optional per-backend modifier tags defaulting to "all backends" when absent) needed a boolean tag expression to reconcile the two dimensions, and let a class desync from the gatekeeper tag specifically - carrying correct modifier tags but missing the gatekeeper meant total invisibility across every lane. Flatten to three peer tags only. Every database test class carries at least one; "applies to all three" means carrying all three tags, explicitly, not carrying none. Lane filtering drops back to plain tag matching, no expression needed: coreUnitTest: excludeTags(h2Tag, mysqlTag, pgTag, dockerTag) coreH2Test: includeTags(h2Tag) coreMySQLTest: includeTags(mysqlTag) corePostgreSQLTest: includeTags(pgTag) Add @AllBackendsTest, a composed annotation that is purely three @tag meta-annotations and nothing else - no @ExtendWith, no execution-time hook, so it stays a discovery-time tag match like the scheme it replaces. TestAllBackendsTest pins the contract directly: it expands to exactly the three backend tags via the same AnnotationSupport lookup JUnit's engine uses at discovery time, and explicitly asserts the annotation carries no execution-time meta-annotation. Migrated all three real usage patterns (parameter-driven multi-backend via storageProvider()/BackendTestSelector, @TestTemplate-driven via BackendTestExtension, and single-backend @nested classes) to the new scheme. Verified against real :core:coreH2Test/:core:coreUnitTest runs: TestJdbcPartitionStatisticStorageIT's per-backend isolation still holds (only the matching nested class's XML is produced), and an @AllBackendsTest class is correctly excluded from coreUnitTest ("No tests found for given includes") and included in coreH2Test. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015k3E9XykKTzbTWaBPwqTyE
…eBackend Raw @tag("gravitino-core-h2-test") string literals (and their multi/-mysql/ -postgresql siblings) were typo-prone: a misspelled tag compiles fine and the class just silently never runs in any lane. @AllBackendsTest already solved this for the all-three-backends case; extend the same discovery-time- safe pattern to the individual-backend case. CoreBackend.H2/.MySQL/.PostgreSQL/.All replace both the raw @tag literals and @AllBackendsTest. Flat names (@CoreH2Test etc.) were considered and rejected: they'd collide with existing classes of those exact names (TestJdbcPartitionStatisticStorageIT$H2Test/$MySQLTest/$PostgreSQLTest) - not just confusingly, but as an actual compile error (an unqualified annotation import shadowed by a same-named nested class). Namespacing under CoreBackend makes that collision structurally impossible (CoreBackend.H2 is always qualified) and matches this package's existing "Backend" vocabulary (BackendTestExtension, BackendTestSelector). A parameterized single annotation (@corebackend(backends = {H2, MYSQL})) was also considered and rejected: JUnit's @tag resolution only ever reads an annotation type's own fixed meta-annotations, never a per-usage attribute value, so it would need an execution-time mechanism to interpret - the same category of mistake the already-reverted @DatabaseTest/ExecutionCondition redesign made. Each nested annotation stays a plain composed @tag with no @ExtendWith; TestCoreDatabaseLaneAnnotations pins the contract directly (exact tag expansion via the same AnnotationSupport lookup Jupiter's engine uses at discovery time, inheritance, stacking, and that none of the four carry an execution-time meta-annotation). Also adds `coreTestLaneOf`, a discovery-only local check (./gradlew :core:coreTestLaneOf -PclassName=<FQCN>) that prints which lane(s) a class's tags put it in without running anything, and warns when a Docker-tagged class carries no backend tag (the one gap this annotation redesign doesn't structurally close: forgetting every backend tag, not just one of several). And a build-script comment on coreBackendTestTags spelling out the four lane-membership shapes with examples. Verified against real :core:coreH2Test/:core:coreUnitTest/:core:coreTestLaneOf runs: TestJdbcPartitionStatisticStorageIT's per-backend isolation still holds (only the matching nested class's XML is produced, manifest passes), and coreTestLaneOf correctly reports lanes for a real @CoreBackend.All class and warns for a synthetic Docker-tagged, no-backend-tag orphan class. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015k3E9XykKTzbTWaBPwqTyE
:core:test is the java plugin's built-in test task, kept registered for tooling backward-compat but no longer the right way to run core tests. Its tasks.test block now warns on every direct invocation, naming the four real lanes (coreUnitTest/coreH2Test/coreMySQLTest/ corePostgreSQLTest) and coreTestLaneOf. No CI change needed since dev/ci/test-shards.sh already excludes it. Adds design-docs/testing/core-db-split.md, an SPIP (Heilmeier Catechism) documenting the final lane-split design retroactively, including the alternatives that were tried and reverted along the way and a contributor how-to (Appendix C) in place of a docs/how-to-test.md section, since that doc is repo-wide and never mentioned core specifically.
TestCoreDatabaseLaneAnnotations' @ParameterizedTest used the default display name, which embeds each case's expected-tags argument (e.g. "[gravitino-core-h2-test]") into its own JUnit XML. That test runs in coreUnitTest, so core_test_identity.py's unit-lane manifest check rejected it as a foreign backend marker - reproduced directly, confirmed with a full 1968-testcase sweep through the real normalize_identity function after the fix, zero marker errors. Fixed by naming on the class under test only. Also, found via two independent Fable reviews: - CoreBackend's Javadoc misattributed core_test_identity.py's reconcile step to core/build.gradle.kts, and its lane-membership bullets didn't mention the docker-tag-only orphan case. Fixed both. - The SPIP's Appendix C taught a partial-backend tagging example (@CoreBackend.H2 @CoreBackend.MySQL) that fails CI's reconcile step unless normalized sibling classes exist for the omitted backends, which only one existing class shape satisfies. Replaced it with guidance to default to @CoreBackend.All and an explicit warning about the constraint.
A class tagged gravitino-docker-test with no CoreBackend tag is excluded from coreUnitTest and from every database lane, and reconcile only compares the database lanes with each other, so it could drop out of all three at once with CI green. TestCoreLaneMembership runs in coreUnitTest and fails, naming each such class.
The root setTestEnvironment reads the flag inside param.doFirst, at execution time, after every register/configureEach action has run, so the core database lanes keep their Docker-tagged tests regardless of configuration order. Comment both ends so the read stays in doFirst.
Only the build suite excludes :core:test. BackendIT's others shard still realizes it through the root test task under -PskipTests, where it matches nothing in core, so the deprecation warning can appear there.
For a class with no tests of its own, such as TestJdbcPartitionStatisticStorageIT, coreTestLaneOf now reports each member test class and its lanes instead of warning that the class runs nowhere. Non-static @nested classes also pick up their enclosing classes' tags. TestCoreLaneMembership reuses the same helpers.
TestCoreLaneMembership now fails coreUnitTest for a Docker-tagged class with no backend tag, so the doc no longer describes that case as unguarded.
Wire coreUnitTest/coreH2Test/coreMySQLTest/corePostgreSQLTest into a core-test matrix job in build.yml directly, so the PR no longer depends on the Backend IT sharding in apache#13495 (dev/ci/test-shards.sh). The build job skips :core:test and uploads its JaCoCo reports; a coverage job merges them with the four core lane .exec files after core-test-contract reconciles the lanes. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019TX7XCnuCMGSJ7xX2iubTH
Drop the design doc, the Python test-identity tool with its tests and fixtures, the core-test-contract job and manifest steps, and the coreTestLaneOf helper task. TestCoreLaneMembership keeps the orphan-lane guard; its two tag helpers move into the test itself.
CoreBackend tags choose the lane; MySQL and PostgreSQL need Docker and H2 does not. gravitino-docker-test on a backend class only keeps it out of coreUnitTest and of legacy :core:test, so an H2-tagged class must not need a container.
Say that an untagged Docker class runs in no lane task (legacy :core:test still runs it with Docker on), say plainly why lane annotations must not carry an execution-time hook, and name what the includeDockerTaggedTests flag actually controls.
Review asked to keep only the core changes, so remove what doesn't earn its keep: - TestCoreDatabaseLaneAnnotations only re-tested JUnit's own @tag meta-annotation and @inherited handling. The lanes themselves and TestCoreLaneMembership already prove the tags select the right tests. - The lane rules were spelled out three times (core/build.gradle.kts, CoreBackend, the :core:test block). CoreBackend's Javadoc is now the one place; the Gradle file points to it. - The coreTestIncludesDockerTaggedTests input property only repeated what the coreTestBackend input already tells Gradle's up-to-date check.
… trivia Review asked to keep only the core changes: - Gradle already writes each Test task's JUnit XML to build/test-results/<task> and its JaCoCo data to build/jacoco/<task>.exec, so the lanes no longer set those paths. The coreTestSuite and coreTestBackend inputs only repeated what includeTags and the backend system property already give the up-to-date check, and the three imports are Kotlin DSL defaults. - validateCoreSuiteCoverage checked that the four .exec files exist, which the coverage job already checks before it copies them. - TestBackendTestSelector no longer pins the six-row legacy matrix or the display-name string through a mocked ExtensionContext; the remaining tests cover selection, validation and the selected-backend matrix.
Contributors had no guide to the new lanes: name the four tasks and when Docker is needed, how a class joins a lane through @corebackend, and how to check a class runs in the lane you expect.
apache#13478 added docs/policies.md as an input and gravitino.repositoryRoot as a system property to :core:test. TestRestrictedRegoGoldenFile is a unit test, so CI runs it in coreUnitTest: give that task the same two settings. The database lanes never run it and get neither.
nevzheng
force-pushed
the
claude/13516-core-injected-databases
branch
2 times, most recently
from
October 14, 2026 18:49
6b496c5 to
13a43ac
Compare
…gain CloseContainerExtension runs for every integration-test module. Making it rethrow turned a slow Docker teardown at the end of a green run into a failed task. Keep ContainerSuite.close() throwing for direct callers, but log in the extension as before.
The fork count and the number of lanes on the command line don't change test results, but as task inputs they made every machine and every task combination miss the build cache.
nevzheng
force-pushed
the
claude/13516-core-injected-databases
branch
from
October 14, 2026 19:30
13a43ac to
501032b
Compare
Each core MySQL or PostgreSQL test task used to start its own container per test JVM. SharedDbContainerService, a Gradle BuildService, now starts one MySQL and one PostgreSQL container for the whole build through the docker CLI, and each backend gets a fresh, uniquely named database on that server instead of a fresh container. - SharedCoreDatabaseProvisioner reads the published admin URL, user and password from system properties and creates the per-backend database. - A core database task that gets no shared server fails fast instead of silently starting its own containers. - Stale containers are reaped only when the Gradle daemon that owns them is gone; PIDs 0 and 1 are never treated as live owners. - The containers use capped tmpfs mounts and durability-off settings that are safe for disposable test data; the tuning args are logged, and container logs are captured when a container never becomes ready. - buildSrc declares gradleApi() so `./gradlew -p buildSrc test` builds on its own. - A README in the tuning resources describes the benchmark machine and how to size the settings.
After the lane split, :core:test still existed beside coreUnitTest and coreH2Test as a deprecated fifth way to run the same tests, and `./gradlew test`/`build` did not match CI. Keeping a command nobody should run is a maintenance risk. :core:test now runs everything core can run without Docker: unit tests and classes tagged for H2, against H2, in one JVM. coreUnitTest and coreH2Test are gone. coreMySQLTest and corePostgreSQLTest stay, join `check` when Docker tests are on, and run nothing under -PskipTests. CI runs three core jobs (h2, mysql, postgresql), and the core report uses the standard test.exec plus the database tasks' exec files, so the coreSuiteCoverage switch is gone.
The MySQL and PostgreSQL core tasks could only start their own Docker containers. On runners where Docker is unavailable or awkward, such as Kubernetes pods with a database service, the tests could not run. When GRAVITINO_TEST_<MYSQL|POSTGRESQL>_URL (with _USER and _PASSWORD) is set, the task uses that server, starts no container and skips the Docker check, and check/build include it. Each fixture still gets a fresh database on that server. The test classes that started containers themselves (AbstractEntityStorageTest and the partition statistics tests) now use the same provisioner, and BackendTestExtension takes the provisioner's credentials instead of assuming root/root. Without the variables, behaviour is unchanged.
Add a core-test-injected job that starts MySQL or PostgreSQL as a GitHub Actions service container, points GRAVITINO_TEST_<BACKEND>_URL at it and runs the matching core task with Docker tests off. The tasks now log [CORE-DB-SOURCE] with the server they use; the job asserts source=injected and that no container besides the service exists, so a misconfigured variable cannot silently fall back to Docker.
Database names were gravitino_core_<worker>_<n>, so a later run against a long-lived injected server reused an earlier run's database and its rows, and CREATE TABLE IF NOT EXISTS hid it. Add a random per-JVM token.
nevzheng
force-pushed
the
claude/13516-core-injected-databases
branch
from
October 14, 2026 19:44
501032b to
b68229d
Compare
Code Coverage Report
|
This was referenced Oct 19, 2026
Collaborator
Author
|
Closing in favor of #13962, which generalizes this into a provider framework for all test services. The injected-database design here will be carried over there. |
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.
What changes were proposed in this pull request?
The core MySQL and PostgreSQL test tasks can use a database the environment provides instead of starting their own Docker container. Injected dependencies win; Docker is the fallback.
GRAVITINO_TEST_MYSQL_URL(an admin JDBC URL) with_USERand_PASSWORD, or theGRAVITINO_TEST_POSTGRESQL_*equivalents.coreMySQLTest/corePostgreSQLTeststart no container, skip the "requires Docker" check, and joincheck/build. Each test fixture still gets its own new database on that server.AbstractEntityStorageTestand the nestedTestJdbcPartitionStatisticStorageITMySQL/PostgreSQL tests) now go through the same provisioner, so a run with an injected database starts no container at all.BackendTestExtensionuses the provisioner's credentials instead of assumingroot/root.AbstractEntityStorageTestand the nestedTestJdbcPartitionStatisticStorageITtests now use the shared container like the rest, instead of starting their own.This PR is the last commit on the stack; the earlier commits belong to #13517, #13518, #13530, #13553 and #13837.
Why are the changes needed?
Testcontainers is a good default for laptops and GitHub-hosted runners, but it assumes the test JVM can reach a Docker daemon. Many CI systems can't offer that easily:
Injecting the database through the environment is the more robust option for those systems: the platform runs the dependency, and the tests only need its address. Testcontainers stays the default, so nothing changes for laptops or the current jobs. Forks and downstream users who run these tests in their own CI, especially on Kubernetes, get a supported path without patching the build.
Related to: #13516
Acceptance test in CI: a new
core-test-injected (mysql|postgresql)job starts the database as a GitHub Actions service container, which is the same shape as a Kubernetes sidecar. It runs the matching core task with Docker tests off and fails unless the task logs[CORE-DB-SOURCE] … source=injectedand no container other than the service exists. The existingcore-testjobs keep covering the Docker fallback.Does this PR introduce any user-facing change?
No production changes. Test-only:
GRAVITINO_TEST_MYSQL_URL/_USER/_PASSWORDandGRAVITINO_TEST_POSTGRESQL_URL/_USER/_PASSWORD.How was this patch tested?
Locally (macOS, JDK 17, Gradle 8.2). MySQL 8.0 and PostgreSQL 13 were started with
docker runoutside Gradle, on non-default ports with non-default credentials, to stand in for injected databases:GRAVITINO_TEST_*set,./gradlew :core:corePostgreSQLTest :core:coreMySQLTest -PskipDockerTests=true:docker ps -abefore and after).root/rootcredentials inBackendTestExtension; fixed here.Database names now carry a random per-JVM token, so a later run on a long-lived server never reuses an earlier run's database.
Without the variables,
-PskipDockerTests=false:TestEntityStorage,TestJdbcPartitionStatisticStorageIT$MySQLTest/$PostgreSQLTest,TestJobMetaServiceand the rest of the selected classes pass on the shared container as before../gradlew :core:spotlessCheck :integration-test-common:spotlessCheck :core:compileTestJavaLocally, simulating the new CI job:
coreMySQLTestwith--testson two classes against a MySQL started outside Gradle loggedsource=injected, passed, and created no container.Future work: the same pattern (use an injected service, fall back to Testcontainers) could cover the other container-backed test dependencies, such as Hive, Kafka, object stores and the catalog integration tests, so whole integration suites can run on Kubernetes.
Stack: #13517 → #13518 → #13530 → #13553 → #13837 → this PR