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.

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

[code-review-assist]

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.

[code-review-assist]

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.

[code-review-assist]

Instead of taking the address of c.Setup.Defaults, consider creating a deep copy of the map. This prevents unintended modifications to the default setup values if a package setup modifies the map it receives. A simple deep copy implementation for map[string]any could be added as a helper function.

Suggested change

	pkg := Package{Path: path, Setup: &c.Setup.Defaults}
	pkg := Package{Path: path, Setup: deepCopy(c.Setup.Defaults)}

[code-review-assist]

The Setup field in the Package struct is a pointer to a map. Consider making it a map directly (Setup map[string]any) unless there's a specific reason for it to be a pointer. Using a map directly simplifies usage and avoids potential nil pointer dereferences. If the intent is to allow a nil value for setup, using a map directly still allows for that by checking if pkg.Setup == nil.

Suggested change

	Setup *map[string]any `json:"setup"`
	Setup map[string]any `json:"setup"`

[code-review-assist]

Add error handling for when ReadJsonc fails. Currently, if ReadJsonc returns an error, the error is not handled, and the execution continues, potentially leading to unexpected behavior. It's crucial to handle this error appropriately, either by logging it, returning it, or taking some other corrective action.

err := ReadJsonc(setup_file, pkg.Setup)
if err != nil {
	fmt.Fprintf(log, "Error reading setup file %q: %v\n", setup_file, err)
	return nil, err
}