voonhous opened a new pull request, #19642: URL: https://github.com/apache/hudi/pull/19642
### Describe the issue this Pull Request addresses Closes #19640. `hudi-trino` pinned released Trino 481 while Trino moved to 483, and the nightly SPI compatibility job has been red against trino master (#19379). Pin-to-pin upgrades arrive as multi-release big-bang migrations; this PR switches master to tracking trinodb/trino master at a pinned commit so SPI fixups land continuously in small deltas. ### Summary and Changelog `hudi-trino` on master now compiles against trinodb/trino master at the commit pinned in the root pom, built from source (Trino publishes no SNAPSHOT artifacts). Releases still pin a released Trino via the documented pin-back steps. - Root pom: `trino.version` becomes `484-SNAPSHOT`, new `trino.sha` (exact trinodb/trino commit, advances only together with `trino.version`) and `trino.e2e.version` (latest released Trino; serves the e2e server image and `trino-jdbc` for integ tests, which must keep resolving from Central). - New `scripts/trino/bootstrap_trino.sh`: one command that validates the pin, purges `~/.m2/repository/io/trino` (stale artifacts from an older pin share the same SNAPSHOT coordinates), and installs the full io.trino module set including the four test-jars and the `trino-root` pom. Used identically by contributors and CI. - `hudi_trino_ci.yml`: restores the built Trino artifacts from an actions cache keyed `trino-m2-v1-<sha>` (no restore-keys on purpose); only a cache miss pays the source build. `scripts/trino/**` added to the trigger paths. - `hudi_trino_compat.yml`: promoted from drift alarm to pin advancement. On a green compile against trino HEAD it saves the cache and force-pushes a `bot/trino-pin` PR (human-merged by policy); the #19379 drift-issue path on failure is unchanged. - `hudi_trino_e2e.yml`: the server image stays the released `trino.e2e.version`; a new SPI drift gate (GitHub compare API over `core/trino-spi`, `lib/trino-filesystem`, `lib/trino-filesystem-manager`, `lib/trino-hdfs`) skips the suite with a job-summary notice when the pin has drifted from it. Image renamed to version-independent `apachehudi/hudi-trino-e2e`. - SPI fixups 481 -> pin: split SPI rewrite (`ConnectorSplitBatch` removed, `getNextBatch(int, DynamicFilterSnapshot)`, `getSplits` with `Set<ColumnHandle>`, dynamic-filter wait via `getRequestedDynamicFilterWaitTimeoutMillis`, plus a `finished` flag mirroring `IcebergSplitSource` so the filter-eliminates-everything path still terminates), `createPageSource` gains `Optional<ConnectorTableCredentials>`, `TypeSignature` -> `TypeDescriptor`, `CacheKeyProvider` returns `CacheKey`, dead `HudiSplit.getSplitInfo()` removed. - Tests: `Hive3MinioDataLake` was deleted upstream; migrated to `Hive3FlociDataLake`/`Floci` and renamed `TestHudiMinioConnectorSmokeTest` to `TestHudiFlociConnectorSmokeTest`. - `jts-core` entered the Trino SPI surface (482): declared `provided` in both `hudi-trino/pom.xml` and the docker shim pom (the SPI dependency check now requires it). - trino-maven-plugin 24 emits only the plugin zip (no exploded dir): the e2e workflow and READMEs unzip it before `build_image.sh`. - Docs: `hudi-trino/README.md` is bootstrap-first; `release/release_guide.md` gains the "hudi-trino Trino pin-back" steps for release branches; stale 481 references cleaned up. No code was copied beyond mirroring upstream trinodb/trino `plugin/trino-hudi` idioms for the SPI migration. ### Impact No storage-format or public-API change. Contributor-facing: on master, `io.trino` artifacts no longer resolve from Maven Central; run the bootstrap script once per pin advance (documented in the module README). Behavior: dynamic-filter waiting is now engine-driven via the split source's requested timeout instead of an internal polling loop; e2e coverage pauses during SPI drift windows between the pin and the latest released Trino. ### Risk Level Medium. The split-source rewrite changes completion semantics (engine relies on `isFinished()` only); mitigated by mirroring upstream's migrated connector and `IcebergSplitSource`, and verified locally with main compile, test-compile (both profiles), javadoc, and the shim plugin build, all green on JDK 25 against the pinned artifacts. CI on this PR exercises the new workflows end to end. One external dependency to confirm: org settings must allow `GITHUB_TOKEN` to open the bot PR; the workflow degrades to pushing the branch with a manual `gh pr create` fallback documented inline. ### Documentation Update `hudi-trino/README.md` (bootstrap-first build), `docker/README.md`, `release/release_guide.md` (pin-back subsection). No config additions or default changes; no website update needed until the next release. ### Contributor's checklist - [x] Read through [contributor's guide](https://hudi.apache.org/contribute/how-to-contribute) - [x] Enough context is provided in the sections above - [x] Adequate tests were added if applicable -- 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]
