Add GCS and ADLS import

[andredlng]

Summary

Adds datacontract import gcs and datacontract import adls, closing the last two file sources that still told users to download an object by hand:

datacontract import gcs  --source s3://my-bucket/orders/*.json       --output datacontract.yaml
datacontract import adls --source abfss://my-container/orders/*.json --output datacontract.yaml

Both guides previously said: download one object with gsutil/az, run import json or import parquet on the local copy, then replace the generated type: local server with the real one, filling in location, format and delimiter.

Almost no new machinery. The S3 importer already read objects through the same duckdb connection the test path uses, and that connection already knew how to authenticate against GCS (setup_gcs_connection) and Azure (setup_azure_connection). One importer now serves all three, so s3_importer.py became object_storage_importer.py. import s3 is unchanged.

The import format and the ODCS server type are deliberately not the same string. ODCS has no adls server type — only azure, which is also the only one the engine dispatches on — so a contract written by import adls still says type: azure and connects as before:

SERVER_TYPES = {"s3": "s3", "gcs": "gcs", "adls": "azure"}

The command is named for what the docs already call this source, "Azure Blob / ADLS", rather than for the server type.

Verification

S3 is verified three ways on the refactored code:

• the MinIO-backed suite, including a round trip that imports a contract and tests it unedited
• a real AWS import against a private bucket with only an SSO session, then datacontract test on the unedited file: 4/4 passed
• the produced contract is byte-identical to the one the pre-refactor importer produced, so the generalisation is provably a no-op for S3

GCS and ADLS reads are not verified against real storage. The repo's existing test_test_gcs_* and test_test_azure_* suites are gated on credentials being set and skip everywhere, including CI, so there was no seam to reuse. The new tests cover what can be checked without a cloud account:

• each storage writes the right server type into the contract, including adls → azure
• each reaches duckdb through its own credential setup, not S3's
• each rejects a missing location

That is weaker than the end-to-end proof the other importers have, and worth weighing before merging. One real import against each would close it.

31 tests pass.

Docs

New imports/gcs.md and imports/adls.md; both testing guides get the one-command step 3. The GCS pages note that duckdb reads Google Cloud Storage through its S3-compatible endpoint, so the location uses s3:// rather than gs:// — a long-standing trap that already had its own troubleshooting entry.

[github-actions]

📖 Docs preview

Preview site: https://brave-water-0cee36e03-1439.westeurope.7.azurestaticapps.net

Changed pages (most-changed first):

• imports/gcs.md — +25/−0
• imports/adls.md — +23/−0
• testing/gcs.md — +5/−14
• testing/azure.md — +5/−13
• imports/index.md — +9/−1
• commands/import.md — +1/−1
• imports/bigquery.md — +1/−1
• imports/csv.md — +1/−1
• imports/databricks.md — +1/−1
• imports/dbml.md — +1/−1
• imports/dbt.md — +1/−1
• imports/excel.md — +1/−1
• imports/iceberg.md — +1/−1
• imports/json.md — +1/−1
• imports/jsonschema.md — +1/−1
• imports/mysql.md — +1/−1
• imports/odcs.md — +1/−1
• imports/parquet.md — +1/−1
• imports/postgres.md — +1/−1
• imports/powerbi.md — +1/−1
• imports/protobuf.md — +1/−1
• imports/snowflake.md — +1/−1
• imports/spark.md — +1/−1
• imports/sql.md — +1/−1
• imports/sqlserver.md — +1/−1
• release-notes.md — +1/−0