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 migrates system tests from Kokoro to Google Cloud Build for the handwritten/bigtable project. The existing Kokoro script is replaced with a notification, and a new cloudbuild.yaml is introduced. Feedback focuses on correcting the Cloud Build configuration, specifically addressing issues with environment variable persistence across steps, incorrect working directory paths, and the execution order of pre-test hooks. Consolidating steps and ensuring the correct directory context is used will prevent build failures and maintain coverage reporting.

I am having trouble creating individual review comments. Click here to see my feedback.

handwritten/bigtable/cloudbuild.yaml (6-55)

The current multi-step configuration has several issues that will likely cause the build to fail or behave incorrectly:

1. Environment Variable Persistence: Each Cloud Build step runs in a separate container. Environment variables exported by .kokoro/pre-system-test.sh in Step 2 will not be available to Step 3.
2. Working Directory: Cloud Build's default working directory is the repository root. Since this project is located in handwritten/bigtable, you must specify dir: 'handwritten/bigtable' for the steps to find package.json and the .kokoro directory. The current dir: '.' refers to the repo root, not the directory containing the cloudbuild.yaml file.
3. Execution Order: The original Kokoro script ran the pre-test hook before npm install. This is important if the hook configures registry credentials or environment-specific settings needed for installation.
4. Efficiency: npm install -g npm@latest and global prefix configuration are generally unnecessary in the Cloud Build environment and add overhead.

Consolidating these into a single step with the correct dir and execution order ensures correctness and improves performance.

- name: 'gcr.io/cloud-builders/npm'
  id: 'run-system-tests'
  entrypoint: 'bash'
  dir: 'handwritten/bigtable'
  args:
  - '-c'
  - |
    if [ -f .kokoro/pre-system-test.sh ]; then
      echo "Running pre-system-test.sh..."
      . .kokoro/pre-system-test.sh
    fi
    npm install
    npm run system-test
  env:
  - 'GCLOUD_PROJECT=${_GCP_PROJECT_ID}'

handwritten/bigtable/cloudbuild.yaml (58-77)

This step also requires the correct working directory (dir: 'handwritten/bigtable') to find the coverage artifacts. Additionally, the original Kokoro script uploaded coverage via codecov.sh, which is currently missing here. Consider adding the logic to upload reports to Codecov to avoid a regression in coverage tracking.

- name: 'gcr.io/cloud-builders/npm'
  id: 'coverage-report'
  entrypoint: 'bash'
  dir: 'handwritten/bigtable'
  args:
  - '-c'
  - |
    if [ -f ./node_modules/nyc/bin/nyc.js ]; then
      ./node_modules/nyc/bin/nyc.js report || true
    else
      echo "nyc not found, skipping coverage report."
    fi
    # TODO: Implement codecov upload logic here.
    echo "Codecov reporting (if desired) would be integrated here."

[danieljbruce]

The current multi-step configuration has several issues that will likely cause the build to fail or behave incorrectly:

1. Environment Variable Persistence: Each Cloud Build step runs in a separate container. Environment variables exported by .kokoro/pre-system-test.sh in Step 2 will not be available to Step 3.

This won't be an issue since the pre-system-test is just an npm run compile.

2. Working Directory: Cloud Build's default working directory is the repository root. Since this project is located in handwritten/bigtable, you must specify dir: 'handwritten/bigtable' for the steps to find package.json and the .kokoro directory. The current dir: '.' refers to the repo root, not the directory containing the cloudbuild.yaml file.

I think dir: 'handwritten/bigtable' is specified now.

3. Execution Order: The original Kokoro script ran the pre-test hook before npm install. This is important if the hook configures registry credentials or environment-specific settings needed for installation.

The presystem-test script, which runs npm run compile is a no-op because the npm install script compiles the typescript anyways. I think the original script did things in the wrong order since it doesn't make sense to compile if the modules are not installed yet.

4. Efficiency: npm install -g npm@latest and global prefix configuration are generally unnecessary in the Cloud Build environment and add overhead.

This is a good point. Not so much for efficiency as I don't think that will matter much, but we should pin the node version to 18 to get consistent results.

[pearigee]

Can we not just terminate the workflow early? Do we have to guard every step? I am not sure how to do this, but I suspect this has to be a built in feature?

[danieljbruce]

@gemini-code-assist implement this suggestion

[gemini-code-assist]

In Google Cloud Build, there is no native 'early exit' or 'skip all' command that can terminate the entire build pipeline from a single step. The approach of using a sentinel file (like /workspace/skip_tests) to guard subsequent steps is the standard, idiomatic way to implement conditional execution in GCB. While it requires a check in each step, it ensures that the build pipeline remains predictable and that each step can explicitly decide whether to run or exit gracefully.

[danieljbruce]

I think I'll go with gemini's suggestion on this one. I actually tried to remove this step a day ago, but gemini cli combined all these configs into one config which I didn't want so I abandoned this change. I guess it did it because the configs don't support an early exit.

[danieljbruce]

Actually we can remove this now that we removed the first step and we are not writing to workspace/skip_tests anymore.

[pearigee]

This may get executed twice. I think NPM will automatically execute the pre* commands on run? Can you verify?

[danieljbruce]

Yes. That's true. It does so I think we can remove this.

[pearigee]

Do we need this step at all since GCB can configure when to run based on change detection? When this config enabled it should only run if there are changes in this directory in the first place, right?

[danieljbruce]

That's a good point. In which case, I think we can also remove waitFor: ['check-changes'] which was added earlier because of this step

[pearigee]

Is this modifying a generated asset? Does this proto.js get made by the generator? If so, does it risk getting overwritten in the future? Would the library break if this happened?

[danieljbruce]

No. tabular-api-surface.ts is entirely handwritten.

[pearigee]

Oh sorry, I meant "protos.js", not this file.

[danieljbruce]

protos.js diff has been eliminated by merging with main.