[Telemetry] Use GitHub API and local caching for metadata retrieval#5589
Conversation
Summary of ChangesHello, I'm Gemini Code Assist1! 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 refactors how standard metadata is retrieved for the toolkit. By moving the logic that fetches module and example information from GitHub directly into the configuration package, the system no longer relies on an external caching tool. This change simplifies the build and deployment process while ensuring that telemetry data remains accurate and up-to-date. Highlights
Using Gemini Code AssistThe 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
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 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. Footnotes
|
There was a problem hiding this comment.
Code Review
This pull request integrates metadata fetching logic directly into the pkg/config package to support telemetry, including functions to retrieve git trees, modules, and example files from GitHub. Review feedback highlights several critical issues: the use of log.Fatalf in library code which could crash the CLI on network errors, the performance impact of performing synchronous network requests during package initialization, and the inefficiency of individual HTTP requests for every example file which risks hitting GitHub API rate limits. It is recommended to refactor these into non-fatal, asynchronous, or hook-based operations.
|
/gemini summary |
Summary of ChangesThis pull request refactors the metadata retrieval process for the toolkit by centralizing the logic within the configuration package. By transitioning from an external Firestore-based caching tool to direct GitHub API calls, the system simplifies its dependency chain and build process. The changes also include robust local caching and improved error handling to ensure telemetry collection remains non-intrusive and resilient to network failures. Highlights
Ignored Files
Activity
|
|
/gemini review |
There was a problem hiding this comment.
Code Review
This pull request refactors the metadata fetching logic to retrieve standard modules, example files, and blueprint names directly from GitHub instead of Firestore. It introduces a local file-based caching mechanism and a concurrent worker pool for efficient data retrieval. Feedback was provided regarding critical error handling in the GitHub API fetch function, specifically addressing a potential nil pointer dereference and a resource leak when the response status is not OK.
daea497
into
GoogleCloudPlatform:develop
Overview
This pull request refactors the metadata retrieval process used for telemetry, centralizing the logic within the
pkg/configpackage. It removes the reliance on the external Firestore-based caching tool and instead fetches data directly using the GitHub API, backed by a robust local file-caching mechanism.Process of Getting Standard Data (In Detail)
This process dynamically retrieves this data with the following steps:
getOrFetchCachedList):Before making any network requests, the system attempts to read the required data from a local JSON cache file located in the user's cache directory (e.g.,
standard_modules_<version>.json). If the cache hits and is successfully parsed, the data is returned immediately.If there is a cache miss, the system falls back to fetching the full file tree for the current toolkit version directly from the GitHub Git Trees API (
https://api.github.com/repos/GoogleCloudPlatform/cluster-toolkit/git/trees/...).The retrieved repository tree is then parsed to identify standard paths:
.tfand.pkr.hclfiles within themodules/andcommunity/modules/directories to build the list of standard modules..yamland.ymlfiles within theexamples/andcommunity/examples/directories.To extract blueprint names efficiently, the system sets up a bounded concurrent worker pool (capped at 10 workers). These workers concurrently fetch the raw content of the identified example YAML files (
https://raw.githubusercontent.com/...) and unmarshal only theblueprint_namefield.Once the standard modules, examples, or blueprint names are successfully fetched, the results are marshaled into JSON format and saved to the local user cache directory to speed up subsequent CLI executions.
Summary of Changes
config.GetPredefinedModules(),config.GetPredefinedExampleFiles(), andconfig.GetStandardBlueprintNames()to handle local file-based caching and GitHub API fallbacks.pkg/telemetry/collector.goto use the new nativeconfig.GetPredefinedModules()functions instead of Viper.tools/cache_metadata/main.goand.github/workflows/cache-metadata.ymlas this functionality is now handled natively within the toolkit.pkg/config/config_test.gousing a mock HTTP transport (mockTransport) to simulate cache hits, network failures, and GitHub API responses.