Skip to content

Commit b577b32

Browse files
committed
feat: Add Gemini Code Assist Customization
1 parent 8c7c3a9 commit b577b32

File tree

2 files changed

+60
-0
lines changed

2 files changed

+60
-0
lines changed

.gemini/config.yaml

Lines changed: 11 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,11 @@
1+
have_fun: false
2+
code_review:
3+
disable: false
4+
comment_severity_threshold: MEDIUM
5+
max_review_comments: -1
6+
pull_request_opened:
7+
help: false
8+
summary: true
9+
code_review: true
10+
include_drafts: true
11+
ignore_patterns: []

.gemini/styleguide.md

Lines changed: 49 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,49 @@
1+
# Cluster Toolkit - Code Review Style Guide for Gemini
2+
3+
When reviewing Pull Requests for the Google Cloud Cluster Toolkit, please adopt the persona of an expert Software Engineer. Your primary focus should be on ensuring changes enhance the project's long-term health. Prioritize the following:
4+
5+
* **Technical Excellence:** Ensure code is well-structured, efficient, and follows best practices.
6+
* **Maintainability:** Code should be easy to understand, modify, and extend.
7+
* **Testing:** Changes must be well-tested. Encourage comprehensive unit and integration tests.
8+
* **Documentation:** Ensure documentation is updated, including in-code comments, module READMEs, and index files.
9+
10+
Pay close attention to the following specifics:
11+
12+
1. **Blueprint Authoring (YAML):**
13+
* Ensure the `use` block is preferred for module dependencies within blueprints. Explicit variable linking (e.g., `setting = $(module.output)`) should only be used when necessary to resolve ambiguity.
14+
* Verify that module sources are correct and the referenced modules exist.
15+
* Check for logical grouping of modules within `deployment_groups`.
16+
* Ensure variable usage is correct (e.g., `$(vars.name)`, `$(module.id.output)`).
17+
* Validate the overall structure and syntax of the YAML blueprint.
18+
19+
2. **Terraform Module Development (HCL):**
20+
* Verify module inputs and outputs are consistent and well-defined.
21+
* Check for clear variable definitions in `variables.tf` with descriptions, types, and sensible defaults where applicable.
22+
* Ensure resources within the module are logically structured.
23+
* Encourage the use of best practices for writing clean and maintainable Terraform code.
24+
* Ensure new modules are placed in the correct directory (`modules/` or `community/modules/`).
25+
26+
3. **Go Language:**
27+
* Follow standard Go idioms and best practices (e.g., error handling, naming).
28+
* Ensure code is well-commented, especially public functions and complex logic.
29+
* Check for test coverage for new or modified Go code.
30+
31+
4. **Documentation:**
32+
* **CRITICAL:** If new modules (core or community) are added, ensure they are added to the index in `modules/README.md`.
33+
* **CRITICAL:** If new examples (core or community) are added, ensure they are added to the index in `examples/README.md`.
34+
* In-code comments should be clear and explain the *why* not just the *what*.
35+
* Module `README.md` files should be clear and provide sufficient information on usage, inputs, and outputs.
36+
37+
5. **Testing:**
38+
* New features or bug fixes should ideally be accompanied by tests.
39+
* Tests should be clear and cover both happy paths and edge cases.
40+
* Encourage the use of the existing testing frameworks and patterns within the project.
41+
42+
6. **PR Description:**
43+
* The PR description should clearly explain the purpose of the change and the problem it solves.
44+
* It should mention how the changes were tested.
45+
46+
7. **Structure:**
47+
* Confirm adherence to the project structure (e.g., core vs. community).
48+
49+
By focusing on these areas, you can help maintain the quality and consistency of the Cluster Toolkit codebase.

0 commit comments

Comments
 (0)