Repository navigation
catalog: replace hardcoded suffix list with deterministic deployment-file matching - #6530
Conversation
…file matching Pair blueprints via exact, longest-prefix, or single-file-in-subfolder match on git-tracked files
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 the blueprint-to-deployment file pairing logic in the catalog generator. By moving away from a fixed list of suffixes to a deterministic matching algorithm, the system becomes more flexible and capable of handling complex directory structures without manual configuration updates. The changes maintain backward compatibility with existing catalog outputs while providing a more predictable resolution strategy. 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 the 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 counterproductive. 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 refactors the companion deployment file matching logic in pkg/catalog/catalog.go to be more deterministic and robust, introducing helpers like trackedDeploymentFiles, matchDeploymentFile, and isExampleSubfolder. It also adds comprehensive unit tests in pkg/catalog/catalog_test.go to verify these pairings. Feedback on the changes suggests refining isExampleSubfolder using strings.HasPrefix to ensure it strictly matches directories within the examples/ or community/examples/ hierarchies, preventing incorrect single-file fallback matching in other repository directories.
… or community/examples/
d58aa11
into
GoogleCloudPlatform:develop
Follow-up to #6481.
What
Replaces the hardcoded suffix list (
-blueprint,-advanced,-infra,-experiment) infindCompanionDeploymentwith a 3-step matcher over git-tracked*-deployment.yaml/deployment.yamlfiles in the blueprint's directory:<stem>-deployment.yamlor<blueprint_name>-deployment.yaml<prefix>-deployment.yamlwhere<stem>starts with<prefix>-(or vice versa)Why
New blueprint naming patterns no longer need a code change to be paired, and multi-blueprint
folders (e.g.
a3-ultragpu-8g/with two blueprints and two deployment files) resolvedeterministically via longest prefix instead of a fixed suffix list.
Behaviour preserved
git ls-files.go run ./tools/catalog-genproduces a byte-identicalcatalog.yamlandexamples/README.md—all 38 existing pairings resolve the same way.
Tests
TestMatchDeploymentFile: 14 table-driven cases (exact beats prefix, longest prefix wins,no partial-word prefix, ambiguous dirs stay unpaired, no fallback at examples root, etc.)
verifyDeploymentPairings: pins one blueprint of every pairing shape in the repo.go test ./pkg/catalog/...,gocyclo -over=13, and pre-commit all pass.