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 in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported 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 or fill out our survey to provide feedback.

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.

packages/system/seaweedfs/charts/seaweedfs/values.yaml (1)

291-318: Duplicate annotations key under volume will shadow the first one

volume.annotations: {} is defined twice:

1. Line 317 – recently added (intended for the ServiceMonitor)
2. Line 443 – existing (for volume resources)

YAML parsers used by Helm will silently keep only the last key, so whichever appears second wins.
Result: the earlier resource-level annotations field becomes unreachable, breaking any user-supplied settings.

Proposed fix – differentiate the concerns:

-  annotations: {}
+  serviceMonitorAnnotations: {}

and update the volume-servicemonitor.yaml template to reference .Values.volume.serviceMonitorAnnotations.

This preserves the original annotations field for volume resources and avoids silent overrides.

Also applies to: 438-445

packages/system/seaweedfs/values.yaml (1)

72-79: Conflicting enableAuth keys – later value overwrites earlier one

enableAuth is defined twice in the same mapping; YAML keeps the last occurrence, so the earlier true is silently discarded and the net effect is enableAuth: false.
This is easy to miss and will disable S3 auth in production.

       metricsPort: 9334
-      enableAuth: true
+      enableAuth: true            # keep a single, definitive key
       readinessProbe:
         scheme: HTTPS
@@
-      enableAuth: false

Remove the duplicate or move the boolean you actually want to the final position.

packages/system/seaweedfs/charts/seaweedfs/templates/volume-servicemonitor.yaml (1)

24-27: Per-volume annotations still not used – loop variable $volume ignored

Inside the range loop you reference the root path $.Values.volume.annotations, so every ServiceMonitor gets the same annotation block and per-volume overrides are impossible.
Use the $volume object that already contains the merged config for the current item.

-{{- if $.Values.volume.annotations }}
+{{- if $volume.annotations }}
   annotations:
-    {{- toYaml $.Values.volume.annotations | nindent 4 }}
+    {{- toYaml $volume.annotations | nindent 4 }}
{{- end }}

packages/extra/monitoring/dashboards.list (1)

40-42: Keep category grouping or alphabetical order consistent

storage/linstor is followed by seaweedfs/seaweedfs.
If all dashboard identifiers under storage/ are meant to be alphabetically-sorted (or logically grouped), consider inserting the new entry in the right position (storage/seaweedfs would normally come before storage/linstor).
Purely cosmetic, but helps avoid merge conflicts later.

hack/download-dashboards.sh (1)

82-86: Minor: path style is inconsistent across the list

Most entries already have a double slash (...dashboards//kubernetes-cluster/...).
The newly added SeaweedFS line follows the same pattern, so it is consistent with the current file, but if you ever normalise the existing paths (single /), remember to adjust this one too.

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

hack/download-dashboards.sh (1)

31-47: Add SeaweedFS branch in the case statement

Without a dedicated branch the SeaweedFS dashboard is written to dashboards/main/, conflicting with dashboards.list. Insert a specific rule before the generic one:

+  *seaweedfs/*)
+    ddir=seaweedfs
+    ;;
   modules/042-kube-dns/*)
     ddir=control-plane
     ;;
   modules/402-ingress-nginx/*)
     ddir=ingress
     ;;
   modules/340-monitoring-kubernetes/*)
     ddir=main
     ;;

Keeps directory naming consistent and avoids broken links.

packages/extra/monitoring/patches/add-seaweedfs-dashboard.patch (1)

8-10: Same directory mismatch as noted earlier

Once the target directory is finalised (see previous comments), update this patch accordingly.

packages/system/seaweedfs/charts/seaweedfs/templates/volume-servicemonitor.yaml (1)

24-26: Consider using per-volume annotations instead of global annotations.

This change fixes the context reference issue but still applies the same global volume.annotations to all volume ServiceMonitors. For better flexibility, consider using the loop variable $volume.annotations to allow per-volume-group ServiceMonitor annotations.

-{{- if $.Values.volume.annotations }}
+{{- if $volume.annotations }}
   annotations:
-    {{- toYaml $.Values.volume.annotations | nindent 4 }}
+    {{- toYaml $volume.annotations | nindent 4 }}
{{- end }}

packages/system/seaweedfs/patches/fix-volume-servicemonitor.patch (1)

8-12: Patch fixes context reference but could benefit from per-volume annotations.

This patch correctly fixes the context reference issue in the vendored SeaweedFS chart. However, the same concern applies here - using $volume.annotations would allow for more flexible per-volume ServiceMonitor configuration.

packages/system/seaweedfs/values.yaml (1)

72-75: S3 metrics configuration added but ServiceMonitor may be missing.

The addition of metricsPort: 9334 and authentication settings for the S3 service are good for monitoring. However, based on past review comments, there may not be a corresponding S3 ServiceMonitor template to scrape these metrics.

Please verify that an S3 ServiceMonitor template exists or add one to ensure the S3 metrics are properly scraped by Prometheus:

#!/bin/bash
# Description: Check if S3 ServiceMonitor template exists in the SeaweedFS chart

# Search for S3 ServiceMonitor template
fd -t f -e yaml . packages/system/seaweedfs/charts/seaweedfs/templates/ --exec grep -l "s3.*ServiceMonitor\|ServiceMonitor.*s3" {} \;

# Also search for any ServiceMonitor templates that might handle S3
fd -t f -e yaml . packages/system/seaweedfs/charts/seaweedfs/templates/ --exec grep -l "kind: ServiceMonitor" {} \;

hack/download-dashboards.sh (1)

84-85: Minor path cleanliness

The new URL contains a double slash (...dashboards//seaweedfs/...). curl accepts it, but removing the extra slash prevents creeping path typos.

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro