[MAINTENANCE] Restore the GCS datasource tests and run them in CI

[joshua-stauffer]

Summary

The 14 tests in the pandas and Spark GCS datasource test modules all failed on develop. They patch:

great_expectations.datasource.fluent.data_asset.data_connector.google_cloud_storage_data_connector.list_gcs_keys

but that module lives at great_expectations.datasource.fluent.data_connector.... — there is no data_asset segment. Every mock.patch raised AttributeError: module '...fluent.data_asset' has no attribute 'data_connector'.

Nothing caught it, because these tests could not run anywhere:

• Both modules skip at import via if not google.storage: pytest.skip(allow_module_level=True).
• google-cloud-storage ships only in reqs/requirements-dev-bigquery.txt.
• The one job that installs it — marker-tests (bigquery) — selects -m bigquery, which matches none of these tests (they were unit / big).

So this PR does two things: corrects the paths, and makes the tests actually run in CI.

Changes

Patch paths corrected in test_pandas_google_cloud_storage_datasource.py and test_spark_google_cloud_storage_datasource.py. This alone takes the 14 tests from failing to passing.

New gcs_deps marker, mirroring the existing aws_deps pattern that already covers the S3 datasource tests — SDK required, no credentials:

reqs/requirements-dev-gcs.txt	new; google-cloud-storage only
tasks.py	MARKER_DEPENDENCY_MAP["gcs_deps"] → that file
pyproject.toml	marker registered
tests/conftest.py	added to REQUIRED_MARKERS
ci.yml	gcs_deps added to the marker-tests matrix

The 16 tests move from unit/big to gcs_deps.

Why a marker rather than adding the SDK to shared requirements: putting google-cloud-storage in requirements-dev-lite.txt would also un-skip tests/datasource/fluent/data_asset/data_connector/test_google_cloud_storage_data_connector.py, which is broken by a separate, unrelated change — AzureBlobStorageDataConnector.__init__() and its GCS sibling no longer accept batching_regex. That would turn CI red. The marker selects only the two modules being fixed here, leaving that one dormant until it is rewritten against the current connector API.

The new requirements file duplicates the google-cloud-storage pin from requirements-dev-bigquery.txt rather than reusing that file, so the leg installs the storage client without the BigQuery SQL stack (sqlalchemy-bigquery, pandas_gbq, gcsfs).

Testing

• pytest -m gcs_deps selects exactly these 16 tests: 14 passed, 2 skipped. The 2 skips are the GOOGLE_APPLICATION_CREDENTIALS gate in test_construct_*_gcs_datasource_without_gcs_options.
• marker-tests writes gcp-credentials.json unconditionally for every leg, so those 2 will execute rather than skip in the new leg. Verified that path works by pointing GOOGLE_APPLICATION_CREDENTIALS at a locally generated throwaway service-account file: all 16 pass, and storage.Client() construction needs no network.
• pytest --verify-marker-coverage-and-exit succeeds (exactly one required marker per test).
• tests/test_packaging.py passes — the new requirements file does not disturb the inter-file set assertions.
• pip install --dry-run -r reqs/requirements-dev-gcs.txt -r reqs/requirements-dev-test.txt -c constraints-dev.txt resolves cleanly.
• ruff check / ruff format clean; invoke type-check --ci clean (757 files + stub-source pass).

Known remaining work, not in this PR

tests/datasource/fluent/data_asset/data_connector/test_{google_cloud_storage,azure_blob_storage}_data_connector.py carry the same stale patch path and 14 tests written against the pre-partitioner connector constructor. Correcting only their paths leaves them failing on TypeError: ... unexpected keyword argument 'batching_regex', so they are untouched here; rewriting them against the current API is a separate change. They remain skipped in CI, exactly as before.

The new leg cannot be exercised by this PR's CI

ci.yml triggers on pull_request_target, and GitHub always evaluates that event against the workflow definition on the base branch. The marker-tests matrix that ran here is develop's, so gcs_deps produced no job — the 15 legs on this PR are the pre-existing set.

Everything the leg does was verified locally instead, by running the exact command the workflow issues:

$ invoke ci-tests 'gcs_deps' --up-services --verbose
pytest -m 'gcs_deps' --durations=5 -rEf -vv
...
14 passed, 4 skipped, 9202 deselected

That covers marker selection, the requirements mapping, and --up-services correctly no-opping on an empty service list (same as aws_deps). What it cannot cover is GitHub materialising a job from the new matrix entry.

Suggestion for whoever merges: route this through the merge queue rather than merging directly. The merge_group event evaluates the workflow from the queue's temporary branch, which does include this change — so the gcs_deps leg will run and gate the merge instead of first appearing on develop after the fact.

[netlify]

✅ Deploy Preview for niobium-lead-7998 canceled.

Name	Link
🔨 Latest commit	8ac02db
🔍 Latest deploy log	https://app.netlify.com/projects/niobium-lead-7998/deploys/6a7c7884828d380008651702