feat: test-isolation package setup configs

[davidcavazos]

Description

Supports package setup configuration files. These allow packages to provide per-package configurations like secrets, environment variables, and the runtime version. Additionally, there are some minor refactors to the existing code, just for better organization, but not changing functionality.

Default values are defined at the config file. The CI setup file is optional where each package can opt-in to custom values. The file lives within the same package directory, so there's no need for contributors to edit the workflows or any of the testing infrastructure.

This file is language agnostic, and it can contain any values, so different workflows or languages could configure them differently.

For this PR, we're also enabling generative-ai tests, which need secrets to run.

Checklist

• I have followed guidelines from CONTRIBUTING.MD and Samples Style Guide
• Tests pass: npm test (see Testing)
• Lint pass: npm run lint (see Style)
• These samples need a new API enabled in testing projects to pass (let us know which ones)
• These samples need a new/updated env vars in testing projects set to pass (let us know which ones)
• This pull request is from a branch created directly off of GoogleCloudPlatform/nodejs-docs-samples. Not a fork.
• This sample adds a new sample directory, and I updated the CODEOWNERS file with the codeowners for this sample
• This sample adds a new sample directory, and I created GitHub Actions workflow for this sample
• This sample adds a new Product API, and I updated the Blunderbuss issue/PR auto-assigner with the codeowners for this sample
• Please merge this PR for me once it is approved

[ghost]

Hi team,

I'm currently reviewing this pull request and will have a full review in a few minutes. In the meantime, here's a quick summary for you and other reviewers to get up to speed:

This pull request, authored by davidcavazos, aims to improve test isolation by introducing package setup configuration files. These configuration files allow packages to specify per-package settings such as secrets, environment variables, and runtime versions.

Here's a breakdown of the changes:

• config.go: This file has been significantly modified to support loading and handling of these new setup configuration files. Specifically:
  • Lines 24-29: Removed the regexp import, simplifying the code.
  • Lines 32-43: Added a Setup struct within the Config struct to handle the setup file's filename and default values.
  • Lines 48-57: Added a Package struct to represent a package with its path and setup configurations.
  • Lines 71-79: Simplified the LoadConfig function by using a helper function to read JSONC files.
  • Lines 156-185: The Affected function was updated to return an array of Package structs, including the setup configurations.
• utils.go: A new helper function ReadJsonc was added (lines 29-40) to handle reading and parsing JSONC files, simplifying the main config loading logic.
• .github/config/nodejs-dev.jsonc and .github/config/nodejs-prod.jsonc: These configuration files were updated to include the new setup section, specifying a setup.json file and default values.
• .github/workflows/ci-dev.yaml: This file was updated (lines 70-81) to use the google-github-actions/get-secretmanager-secrets@v2 action to retrieve secrets defined in the setup.json files.
• generative-ai/snippets/setup.json: A sample setup.json file was added, demonstrating how to define secrets and Node.js version.

Several files also had lines removed related to the previous comment handling logic, which is now handled by the new ReadJsonc function. The functions/http/uploadFile sample was also removed from the ignore list in the production config file.

I'll provide a more detailed review shortly. In the meantime, please let me know if you have any questions.

And now, a little haiku to brighten your day:

Tests run, green light shows,
Configs now make setup smooth,
Code flows, clean and bright.

[ghost]

This pull request introduces support for per-package setup configuration files, which is a valuable addition. The implementation looks good overall, but there are a few points to address regarding consistency, error handling, and best practices.

[briandorsey]

Very high level review without running it myself, but overall LGTM.

[briandorsey]

Double-checking... looks like run-all didn't exist before this PR? (context: didn't see "run-all" in the switch command { section.)

[davidcavazos]

Yes, run-all came from another experiment that was removed, but forgot to update this.

[telpirion]

Only nits. Looks good!

[telpirion]

praise: I love the comments here that help me interpret what the code is doing.