test: cover Iceberg REST catalog backend in CI#4276
test: cover Iceberg REST catalog backend in CI#4276mengw15 wants to merge 2 commits intoapache:mainfrom
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #4276 +/- ##
============================================
+ Coverage 43.21% 43.22% +0.01%
- Complexity 2185 2186 +1
============================================
Files 1035 1035
Lines 38843 38843
Branches 4061 4061
============================================
+ Hits 16785 16789 +4
+ Misses 21006 21004 -2
+ Partials 1052 1050 -2
☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
@Yicong-Huang ready for review! |
|
Per offline discussion, I think this integration test better to be moved into |
a940bc3 to
eff01b6
Compare
Yicong-Huang
left a comment
There was a problem hiding this comment.
LGTM. left several comments inline, please take care of them. Thanks!
| curl -sf -X POST -H 'Content-Type: application/json' -d '{ | ||
| "warehouse-name": "texera", | ||
| "project-id": "00000000-0000-0000-0000-000000000000", | ||
| "storage-profile": { | ||
| "type": "s3", | ||
| "bucket": "texera-iceberg", | ||
| "region": "us-west-2", | ||
| "endpoint": "http://localhost:9000", | ||
| "flavor": "s3-compat", | ||
| "path-style-access": true, | ||
| "sts-enabled": false | ||
| }, | ||
| "storage-credential": { | ||
| "type": "s3", | ||
| "credential-type": "access-key", | ||
| "aws-access-key-id": "texera_minio", | ||
| "aws-secret-access-key": "password" | ||
| } |
There was a problem hiding this comment.
do those config live some where in our codebase? can we point there instead? this is to avoid the need to update this CI file when we need to change some parameter.
There was a problem hiding this comment.
Good question — these values do have a runtime source-of-truth in common/config/src/main/resources/storage.conf, but it is not easily readable from a bash CI step.
Wire Lakekeeper + MinIO into the existing `amber-integration` CI job and add focused integration specs that round-trip table metadata via the REST catalog from both the Scala and Python clients. `amber-integration`'s setup now boots MinIO + Lakekeeper (migrate -> serve -> healthcheck), creates the `texera_lakekeeper` DB, initializes the warehouse with an S3 storage profile, installs `dev-requirements` for pytest, and exposes the REST URI / S3 env vars to the test steps. - `IcebergRestCatalogIntegrationSpec` (Scala, `@IntegrationTest`) builds a `RESTCatalog` directly via `IcebergUtil.createRestCatalog` and scopes it through `IcebergCatalogInstance.replaceInstance`, restoring the prior singleton in `afterAll`. The catalog *type* is intentionally not flipped to `rest` globally, so other `@IntegrationTest` specs in the same job keep their existing Postgres-catalog backend. - `test_iceberg_rest_catalog_integration.py` (Python) mirrors the Scala spec and is tagged `pytest.mark.integration` — the Python equivalent of the Scala `@IntegrationTest` tag. The regular `python` job runs with `-m "not integration"` and excludes it; `amber-integration` selects it via `-m integration`. Marker registered in `amber/pyproject.toml`. Closes apache#4994
What changes were proposed in this PR?
Add two
@IntegrationTest-tagged specs that round-trip table metadatavia the Iceberg REST catalog against a live Lakekeeper + MinIO stack
brought up by the existing
amber-integrationCI job:IcebergRestCatalogIntegrationSpec(Scala)test_iceberg_rest_catalog_integration.py(Python, markedpytest.mark.integration)The
amber-integrationjob now boots MinIO + Lakekeeper, initializes awarehouse with an S3 storage profile, installs
dev-requirements.txtfor pytest, and runs
pytest -m integrationafter the existing sbtstep. The regular
pythonjob runs with-m "not integration"so thenew Python test is excluded there. The
integrationmarker isregistered in
amber/pyproject.tomlas the Python equivalent of theScala
@IntegrationTestJava tag.Any related issues, documentation, discussions?
Closes #4994 (sub-issue of #4126).
How was this PR tested?
CI itself — the new specs run as part of
amber-integrationon everypush of this PR; Lakekeeper boot / warehouse init / REST-path
breakage all surface on that job's status check.
Was this PR authored or co-authored using generative AI tooling?
Generated-by: Claude Code (Opus 4.7)