test: run the bigtable system tests in google cloud build

[danieljbruce]

Description

This pull request adds a yaml file to instruct the Bigtable system test CI check to work with the new Cloud Build trigger thereby making the new CI check effectively run our system tests. It also includes minor code modifications to the Bigtable handwritten layer that allow the system tests to operate properly in the new Cloud Build Environment.

Impact

Leverages the strengths of running system tests in GCB rather than relying on kokoro for system tests.

Testing

This pull request tells the tests how to work with the new check to the continuous integration pipeline for the Bigtable system tests thus improves the effectiveness of that test.

Next Steps

1. Merge a pull request that removes the system tests from kokoro. This should be done in a separate pull request to separate the concerns of removing the kokoro system tests from adding the Google Cloud Build system tests.
2. Distribute a document detailing the process for migrating system tests from kokoro to GCB for all handwritten libraries.

[gemini-code-assist]

Code Review

This pull request introduces a Cloud Build configuration for Bigtable system tests and refactors the tabular-api-surface.ts file to avoid importing from internal google-gax paths by defining a local StrictLongRunningType. It also fixes pack-n-play test issues by adding necessary node type references. Feedback includes recommendations to avoid global npm updates in CI, use standard binary paths for nyc, remove hardcoded project IDs, reduce build timeouts, and export the newly created type for external visibility.

[gemini-code-assist]

Updating npm globally and changing the configuration prefix in a CI environment is generally discouraged as it can lead to non-deterministic builds and potential permission issues. The gcr.io/cloud-builders/npm image should already provide a functional npm version. If a specific version of Node.js or npm is required, it is better to use a specific image tag or pin the version explicitly.

    if [ -f /workspace/skip_tests ]; then exit 0; fi
    npm install
    npm run presystem-test

[danieljbruce]

On the other PR I committed a code change to fix the node version.

[gemini-code-assist]

Avoid reaching into the internal directory structure of a package to execute its binary. It is more robust to use the binary located in node_modules/.bin/ or use npx.

    if [ -f ./node_modules/.bin/nyc ]; then
      ./node_modules/.bin/nyc report || true # || true prevents build failure if nyc report itself exits non-zero

[danieljbruce]

Maybe, but not a serious issue since the old scripts did it this way anyways.

[gemini-code-assist]

Hardcoding a specific GCP Project ID (long-door-651) in the configuration makes the build script less reusable and can leak internal infrastructure details. Consider using a placeholder or leaving it empty if it's intended to be provided via a build trigger.

  _GCP_PROJECT_ID: 'your-project-id'

[danieljbruce]

This value was shared before therefore sharing the specific id has no downside.

[gemini-code-assist]

The timeout is set to 10800 seconds (3 hours), which is quite high for system tests. If tests hang, this could lead to significant resource consumption. Consider reducing this to a more reasonable value (e.g., 3600s) based on the expected execution time.

timeout: '3600s'

[danieljbruce]

No. We need this much time.

[gemini-code-assist]

The type StrictLongRunningType is used in the signature of the exported function getNextDelay and the exported constant DEFAULT_BACKOFF_SETTINGS. To ensure that consumers of this library can correctly reference the type, it should also be exported.

Suggested change

	type StrictLongRunningType = NonNullable<CallOptions['longrunning']>;
	export type StrictLongRunningType = NonNullable<CallOptions['longrunning']>;

[danieljbruce]

The constant and the function are internal

[danieljbruce]

Duplicate