Refactor spanner-staging-tests

[aasthabharill]

b/534589929

This PR refactors the Spanner staging integration test pipeline to dynamically change the run-name to different testing environments (Production, Staging, Cloud-devel).

Changes and Intent

1. Added a dynamic run-name expression in .github/workflows/spanner-staging-tests.yml

Because this workflow runs against three different Spanner hosts (Prod, Staging, Cloud-devel), distinguishing the runs in the GitHub Actions UI was difficult. Test runs will now clearly identify their target environment (e.g., "Spanner Cloud-devel Integration Tests").

2. Removed the explicit spannerHost input configuration from the pull_request block to avoid masking defaults

• pull_request triggers don't accept the inputs parameter - so the workflow that this PR triggered had no Spanner host set, which is incorrect. (Workflow link)
• Added fallback to cloud-devel URL in the job env block to rectify this issue

3. Removed @RunWith(JUnit4.class) from CobyDbIT and CopyDbRandomisedIT test files

• These classes inherit from SpannerTemplateITBase (which defines @RunWith(Parameterized.class) to inject the custom spannerHost), but the JUnit4 annotation overrode the parameterization.
• This caused the spannerHost variable to remain null in those tests.
• SpannerResourceManager silently bypassed the custom host configuration and defaulted to the standard PROD Spanner endpoint (https://spanner.googleapis.com) even in staging/cloud-devel workflows.

4. Changed PARTITION_ID to default instead of creating a new one

• When a spanner instance is created, Spanner implicitly provisions a built-in partition named "default" that shares the instance's region configuration.
• Spanner strictly prohibits creating a new custom instance partition that shares the exact same region as another partition - so we can't use the spanner instance region due to the default partition that was created
• Therefore, to successfully create a custom partition, the base instance must be created in one configuration (e.g., nam3), and the custom partition must be created in a different configuration (e.g., nam6).
• But across our three environments (Prod, Pre-Prod, and Cloud-devel), there isn't a universally shared set of two distinct multi-region configurations.
• So we will utilize the default partition instead of provisioning a secondary partition.
• This change will ensure the tests work for cloud-devel and production code

Tests

• Verified that the run name dynamically changes depending on the Spanner Host passed.
• This PR triggers the Spanner Staging Tests. The test correctly used the cloud-devel spanner host URL.

https://screenshot.googleplex.com/4Ew96Vt3ckq9mnh.png

• The CopyDbIT tests run on the correct host:

https://screenshot.googleplex.com/5YA3kPQctVuYCps.png

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 55.68%. Comparing base (06d6601) to head (5c20ee0).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #4017      +/-   ##
============================================
- Coverage     55.70%   55.68%   -0.03%     
+ Complexity     7237     6782     -455     
============================================
  Files          1124     1124              
  Lines         68447    68447              
  Branches       7721     7721              
============================================
- Hits          38130    38116      -14     
- Misses        27843    27856      +13     
- Partials       2474     2475       +1     

Components	Coverage Δ
spanner-templates	87.66% <ø> (ø)
spanner-import-export	68.57% <ø> (-0.13%)	⬇️
spanner-live-forward-migration	89.29% <ø> (ø)
spanner-live-reverse-replication	83.46% <ø> (ø)
spanner-bulk-migration	92.48% <ø> (ø)
gcs-spanner-dv	88.55% <ø> (ø)
see 6 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request refactors the Spanner staging integration test pipeline to improve environment identification and fix configuration issues. By adjusting how Spanner partitions are handled and correcting JUnit test runners, the changes ensure that integration tests correctly target the intended environments and utilize the appropriate Spanner host configurations.

Highlights

• Workflow Enhancements: Added a dynamic run-name expression to the Spanner staging tests workflow to improve visibility in the GitHub Actions UI and removed the invalid inputs parameter from the pull_request trigger.
• Spanner Partition Configuration: Updated the partition ID to 'default' in InformationSchemaScannerIT to resolve conflicts with Spanner's built-in partition requirements.
• Test Infrastructure Fixes: Removed @RunWith(JUnit4.class) from CopyDbIT and CopyDbRandomisedIT to ensure proper parameterization via SpannerTemplateITBase and updated categories for better test execution.

Ignored Files

• Ignored by pattern: .github/workflows/** (1)
  • .github/workflows/spanner-staging-tests.yml

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request cleans up JUnit 4 runner annotations across several integration tests and updates the test categories for CopyDbRandomisedIT. Additionally, in InformationSchemaScannerIT, the instance partition configuration is simplified by defaulting to the "default" partition and changing the region to "nam3". The reviewer recommends using TestProperties.region() instead of hardcoding "nam3" to ensure test portability across different GCP environments.

[gemini-code-assist]

Hardcoding the Spanner instance configuration region to "nam3" can cause integration test failures in environments or GCP projects where nam3 is restricted or unavailable (e.g., due to organization policies). To ensure the tests are portable and consistent with setupSharedResourceManagers (which uses TestProperties.region()), we should use TestProperties.region() instead of a hardcoded string.

Suggested change

	SpannerResourceManager.Builder builder =
	SpannerResourceManager.builder(
	testName + "-" + UUID.randomUUID().toString().substring(0, 8),
	projectId,
	"nam6",
	dialect)
	.setInstancePartition(INSTANCE_PARTITION_ID, "nam3");
	testName + "-" + UUID.randomUUID().toString().substring(0, 8),
	projectId,
	"nam3",
	dialect);
	SpannerResourceManager.Builder builder =
	SpannerResourceManager.builder(
	testName + "-" + UUID.randomUUID().toString().substring(0, 8),
	projectId,
	TestProperties.region(),
	dialect);