Release candidate: v1.74.0 (GoogleCloudPlatform#4925)

Author: aslam-quad

.gemini/config.yaml

@@ -0,0 +1,25 @@
+# Copyright 2025 "Google LLC"
+#
+# Licensed under the Apache License, Version 2.0 (the "License");
+# you may not use this file except in compliance with the License.
+# You may obtain a copy of the License at
+#
+#     http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS,
+# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+# See the License for the specific language governing permissions and
+# limitations under the License.
+
+have_fun: false
+code_review:
+  disable: false
+  comment_severity_threshold: MEDIUM
+  max_review_comments: -1
+  pull_request_opened:
+    help: false
+    summary: true
+    code_review: true
+    include_drafts: true
+ignore_patterns: []

.gemini/styleguide.md

@@ -0,0 +1,49 @@
+# Cluster Toolkit - Code Review Style Guide for Gemini
+
+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:
+
+* **Technical Excellence:** Ensure code is well-structured, efficient, and follows best practices.
+* **Maintainability:** Code should be easy to understand, modify, and extend.
+* **Testing:** Changes must be well-tested. Encourage comprehensive unit and integration tests.
+* **Documentation:** Ensure documentation is updated, including in-code comments, module READMEs, and index files.
+
+Pay close attention to the following specifics:
+
+1. **Blueprint Authoring (YAML):**
+   * 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.
+   * Verify that module sources are correct and the referenced modules exist.
+   * Check for logical grouping of modules within `deployment_groups`.
+   * Ensure variable usage is correct (e.g., `$(vars.name)`, `$(module.id.output)`).
+   * Validate the overall structure and syntax of the YAML blueprint.
+
+2. **Terraform Module Development (HCL):**
+   * Verify module inputs and outputs are consistent and well-defined.
+   * Check for clear variable definitions in `variables.tf` with descriptions, types, and sensible defaults where applicable.
+   * Ensure resources within the module are logically structured.
+   * Encourage the use of best practices for writing clean and maintainable Terraform code.
+   * Ensure new modules are placed in the correct directory (`modules/` or `community/modules/`) and within the appropriate subdirectory (e.g., `compute`, `network`, `file-system`, `scheduler`, etc.).
+
+3. **Go Language:**
+   * Follow standard Go idioms and best practices (e.g., error handling, naming).
+   * Ensure code is well-commented, especially public functions and complex logic.
+   * Check for test coverage for new or modified Go code.
+
+4. **Documentation:**
+   * **CRITICAL:** If new modules (core or community) are added, ensure they are added to the index in `modules/README.md`.
+   * **CRITICAL:** If new examples (core or community) are added, ensure they are added to the index in `examples/README.md`.
+   * In-code comments should be clear and explain the *why* not just the *what*.
+   * Module `README.md` files should be clear and provide sufficient information on usage, inputs, and outputs.
+
+5. **Testing:**
+   * New features or bug fixes should ideally be accompanied by tests.
+   * Tests should be clear and cover both happy paths and edge cases.
+   * Encourage the use of the existing testing frameworks and patterns within the project.
+
+6. **PR Description:**
+   * The PR description should clearly explain the purpose of the change and the problem it solves.
+   * It should mention how the changes were tested.
+
+7. **Structure:**
+   * Confirm adherence to the project structure (e.g., core vs. community).
+
+By focusing on these areas, you can help maintain the quality and consistency of the Cluster Toolkit codebase.

.github/workflows/pr-description-check.yml

@@ -0,0 +1,70 @@
+# Copyright 2025 "Google LLC"
+#
+# Licensed under the Apache License, Version 2.0 (the "License");
+# you may not use this file except in compliance with the License.
+# You may obtain a copy of the License at
+#
+#     http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS,
+# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+# See the License for the specific language governing permissions and
+# limitations under the License.
+
+name: Check PR Description
+on:
+  pull_request:
+    types:
+    - opened
+    - edited
+    - synchronize
+jobs:
+  check-description:
+    runs-on: ubuntu-latest
+    steps:
+    - name: Checkout repository
+      uses: actions/checkout@v4
+    - name: Check PR description
+      env:
+        PR_BODY: ${{ github.event.pull_request.body }}
+      run: |
+        TEMPLATE_PATH=".github/pull_request_template.md"
+
+        if [ -f "$TEMPLATE_PATH" ]; then
+          TEMPLATE_BODY=$(cat "$TEMPLATE_PATH")
+        else
+          TEMPLATE_BODY=""
+        fi
+
+        # Function to normalize text: removes empty lines, trims leading/trailing whitespace, and removes carriage returns
+        normalize_text() {
+          echo -n "$1" | tr -d '\r' | awk 'NF' | awk '{$1=$1};1'
+        }
+
+        # 1. Check if the PR body is empty or contains only whitespace
+        if [ -z "$(echo "$PR_BODY" | tr -d '[:space:]')" ]; then
+          echo "Error: PR description is empty or contains only whitespace."
+          exit 1
+        fi
+
+        # 2. Check if the PR body is identical to the template
+        NORMALIZED_PR_BODY=$(normalize_text "$PR_BODY")
+        NORMALIZED_TEMPLATE_BODY=$(normalize_text "$TEMPLATE_BODY")
+
+        if [[ "$NORMALIZED_PR_BODY" == "$NORMALIZED_TEMPLATE_BODY" ]]; then
+          echo "Error: PR description only contains the template text. Please add a description of your changes."
+          exit 1
+        fi
+
+        # 3. Check if at least 10 characters have been added to the description
+        #    Use `diff` to isolate the added lines between the template and the PR body.
+        ADDED_TEXT=$(diff --changed-group-format="%>" --unchanged-group-format="" <(echo "$NORMALIZED_TEMPLATE_BODY") <(echo "$NORMALIZED_PR_BODY") || true)
+        ADDED_TEXT_LEN=${#ADDED_TEXT}
+
+        if [[ "$ADDED_TEXT_LEN" -lt 10 ]]; then
+          echo "Error: PR description must contain at least 10 added characters."
+          exit 1
+        fi
+
+        echo "PR description check passed."

.pre-commit-config.yaml

@@ -74,6 +74,15 @@ repos:
     files: 'tools/cloud-build/daily-tests/builds/.*\.yaml'
     pass_filenames: false
     require_serial: true
+  - id: validate-daily-test-builds
+    name: validate-daily-test-builds
+    entry: tools/cloud-build/daily-tests/validate_daily_test_builds.py
+    language: python
+    language_version: python3
+    additional_dependencies: ['pyyaml']
+    files: 'tools/cloud-build/daily-tests/builds/.*\.(yaml|yml)'
+    pass_filenames: true
+    require_serial: true
   - id: pytest-check
     name: pytest-check
     entry: python -m pytest

Makefile

@@ -73,7 +73,7 @@ install-dev-deps: warn-terraform-version warn-packer-version check-pre-commit ch
 	go install honnef.co/go/tools/cmd/staticcheck@latest
 	pip install -r community/modules/scheduler/schedmd-slurm-gcp-v6-controller/modules/slurm_files/scripts/requirements.txt
 	pip install -r community/modules/scheduler/schedmd-slurm-gcp-v6-controller/modules/slurm_files/scripts/requirements-dev.txt
-	pip install mypy
+	pip install mypy==1.18.2
 
 
 clean: