fix: Adding output types to metadata.yaml for gke-standard-cluster

[Saranya3]

Added output type to metadata.yaml inorder to make connections to the gke-standard-cluster and deploy the same with connections.
Ref: https://g3doc.corp.google.com/cloud/config/gcpblueprints/g3doc/design_center.md#1-generate-output-type-in-metadata

[gemini-code-assist]

Summary of Changes

Hello @Saranya3, 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 updates the metadata.yaml file for the gke-standard-cluster module by adding detailed output type definitions. This enhancement is crucial for establishing proper connections and facilitating the deployment of GKE standard clusters, ensuring that the metadata accurately reflects the structure and types of the cluster's outputs, thereby aligning with established design guidelines for metadata generation.

Highlights

• Output Type Definitions: Added explicit type definitions for various output fields within the metadata.yaml file for the gke-standard-cluster module.
• Detailed Addons Configuration: Introduced a comprehensive type definition for the addons_config output, detailing configurations for numerous GKE addons such as Cloud Run, Config Connector, various CSI drivers, and more.
• Master Authorized Networks Configuration: Provided a structured type definition for master_authorized_networks_config, including details for CIDR blocks and public/private endpoint enforcement.
• Basic Type Assignments: Assigned basic types (string, boolean, or set of strings) to other GKE cluster output fields like ca_certificate, cluster_id, location, and various _enabled flags.

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 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 counter productive. 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.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

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 correctly adds type definitions for most of the outputs in metadata.yaml for the gke-standard-cluster module. This is a good improvement for metadata completeness and will help with tooling that consumes this file. I have one suggestion to add a missing type definition for one of the outputs to make the change complete.

[Daisyprakash]

LGTM

[anshukaira]

/gcbrun

[Saranya3]

@apeabody unable to start the test for the PR: terraform-google-kubernetes-engine-int-trigger (cloud-foundation-cicd)
Also, please let me know if something is pending in the PR that needs to be checked.

[apeabody]

/gemini review

[apeabody]

@apeabody unable to start the test for the PR: terraform-google-kubernetes-engine-int-trigger (cloud-foundation-cicd) Also, please let me know if something is pending in the PR that needs to be checked.

Hi @Saranya3 - The Int Test isn't required as this change is only to metadata which is covered by the Lint check.

[gemini-code-assist]

Code Review

This pull request adds output type definitions to the metadata.yaml file for the gke-standard-cluster module. While this is a necessary change for blueprint tooling, the implementation contains critical YAML syntax errors and schema inaccuracies that will likely cause parsing failures. I've identified issues in the type definitions for addons_config and master_authorized_networks_config, including incorrect data types, invalid fields, and incorrect YAML indentation. These need to be addressed to ensure the metadata is valid and correct.

[apeabody]

Thanks for the contribution @Saranya3 - Please review the Gemini feedback for relevance.

[Saranya3]

/gemini review

[gemini-code-assist]

Code Review

This pull request adds output type definitions to the metadata.yaml for the gke-standard-cluster module. This is a valuable change for improving tooling integration that consumes this metadata. I've found a structural inconsistency in the new YAML type definitions for the addons_config output, which could cause issues for parsing tools. My review includes a suggestion to correct this for consistency with other object definitions in the file.

[apeabody]

/gemini review

[gemini-code-assist]

Code Review

This pull request adds type definitions to all outputs in modules/gke-standard-cluster/metadata.yaml. This change is crucial for enabling automated tooling to correctly interpret and connect to the outputs of this GKE standard cluster blueprint. The added types, ranging from simple scalars to complex nested objects, appear to be correctly defined and consistently follow the expected YAML structure for blueprint metadata. The changes look good and address the goal stated in the pull request description.

[apeabody]

Thanks @Saranya3!