chore(helm): switch MariaDB chart to CloudPirate#881
Conversation
When no image tag is defined in the Deployment template, helm falls back to the appVersion to know which tag to pull.
📝 WalkthroughWalkthroughUpdated Helm chart and templates: MariaDB dependency changed repository and fixed version; Deployment template now references Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
✨ Simplify code
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
deploy/helm/grimmory/Chart.yaml (1)
16-16: 🛠️ Refactor suggestion | 🟠 MajorBump chart
versionalong with the breaking subchart switch.The MariaDB subchart change (Bitnami → CloudPirates) is a breaking change to this chart's effective values surface (e.g. consumers who set
mariadb.primary.service.ports.mysql,mariadb.auth.existingSecretsemantics, etc., will silently break). Per Helm SemVer guidance, the parent chartversionshould be incremented (at minimum a minor bump while pre-1.0, or major if you treat it as 1.0+). Leaving it at0.1.0makes upgrades indistinguishable from the previous release.📦 Suggested bump
-version: 0.1.0 +version: 0.2.0🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@deploy/helm/grimmory/Chart.yaml` at line 16, The Chart.yaml version remains at 0.1.0 even though the MariaDB subchart was switched (a breaking change); update the Chart.yaml `version` field to a higher SemVer so upgrades are distinguishable—e.g., bump the Chart.yaml `version` from 0.1.0 to at least 0.2.0 (for pre-1.0 minor bump) or to a major version if you treat it as 1.x, commit the updated Chart.yaml `version` to reflect the breaking subchart change.deploy/helm/grimmory/templates/deployment.yaml (1)
69-77:⚠️ Potential issue | 🔴 Critical
mariadb-passwordsecret key does not match CloudPirates MariaDB chart defaults — useuser-passwordinstead.The grimmory Helm chart depends on CloudPirates' MariaDB chart (v0.16.*), which creates secrets with the key
user-passwordby default (viaauth.secretKeys.userPasswordKey). The current hardcodedkey: mariadb-passwordon line 77 will cause the pod to fail at startup: either the secret key reference will fail, or the pod will start with an empty password and fail authentication.When using CloudPirates' default secret, replace
key: mariadb-passwordwithkey: user-password. When using a customexistingSecret, respect the chart'ssecretKeys.userPasswordKeyconfiguration:Suggested fix
- name: DATABASE_PASSWORD valueFrom: secretKeyRef: {{- if .Values.mariadb.auth.existingSecret }} name: {{ .Values.mariadb.auth.existingSecret }} + key: {{ .Values.mariadb.auth.secretKeys.userPasswordKey | default "user-password" }} {{- else }} name: {{ .Release.Name }}-mariadb + key: user-password {{- end }} - key: mariadb-password🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@deploy/helm/grimmory/templates/deployment.yaml` around lines 69 - 77, The env var DATABASE_PASSWORD currently references a hardcoded secret key "mariadb-password" which is incompatible with the CloudPirates MariaDB chart default; update the secretKeyRef key to use the MariaDB chart's user password key instead (use "user-password" as the default) and honor any configured override in the chart values. Concretely, replace the static key: mariadb-password with a templated expression that defaults to "user-password" but uses .Values.mariadb.auth.secretKeys.userPasswordKey when provided (and keep the existing logic around .Values.mariadb.auth.existingSecret and the release-named secret unchanged).
🧹 Nitpick comments (1)
deploy/helm/grimmory/templates/deployment.yaml (1)
39-44: Init-container is fine, but consider hardcoding the well-known MariaDB port 3306 as a fallback.Reading the port through
.Values.mariadb.service.portis reasonable, but if a future user disables the subchart (mariadb.enabled: false) and pointsDATABASE_URLat an external DB,mariadb.service.portmay be unset and both the init-containeruntilloop and the JDBC URL render to…:. Adefault 3306would make the template self-healing:♻️ Suggested defensive default
- echo "Waiting for database on port {{ .Values.mariadb.service.port }}..." - until nc -z -v -w5 {{ .Release.Name }}-mariadb {{ .Values.mariadb.service.port }}; do + echo "Waiting for database on port {{ .Values.mariadb.service.port | default 3306 }}..." + until nc -z -v -w5 {{ .Release.Name }}-mariadb {{ .Values.mariadb.service.port | default 3306 }}; do…and similarly in the
DATABASE_URLline below.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@deploy/helm/grimmory/templates/deployment.yaml` around lines 39 - 44, The init-container waiting loop uses .Values.mariadb.service.port directly so if the mariadb subchart is disabled the port becomes empty and the nc check and the rendered DATABASE_URL end up with a trailing colon; update the template to use a defensive default port (3306) wherever .Values.mariadb.service.port is referenced (e.g., in the init-container nc until loop and the DATABASE_URL rendering) by applying Helm's default/ternary operator to fall back to 3306 (keep the same variable names like .Values.mariadb.service.port and .Release.Name so the change is minimal and localized).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@deploy/helm/grimmory/Chart.yaml`:
- Around line 23-25: Update the mariadb dependency entry (name: mariadb) to pin
to a real tested patch release instead of the non-existent 0.16.*; change the
version field to a tilde-pinned patch like ~0.14.3 (or ~0.14.0) and replace the
float pattern, and add a brief comment above the dependency with the upstream
Helm chart README/values reference URL for future maintainers so
Renovate/Dependabot can manage upgrades safely.
In `@deploy/helm/grimmory/values.yaml`:
- Around line 5-13: The mariadb auth block in values.yaml is missing required
credentials so helm will fail; update the mariadb configuration under the
mariadb key to either provide passwords (set auth.password and/or
auth.rootPassword) or point to an existing secret (set auth.existingSecret and,
if needed, auth.secretKeys.userPasswordKey/rootPasswordKey) and document which
approach is used; ensure you modify the mariadb.auth section (and optionally add
explanatory comments) so the CloudPirates MariaDB chart receives valid
credentials for database: grimmory and username: grimmory.
---
Outside diff comments:
In `@deploy/helm/grimmory/Chart.yaml`:
- Line 16: The Chart.yaml version remains at 0.1.0 even though the MariaDB
subchart was switched (a breaking change); update the Chart.yaml `version` field
to a higher SemVer so upgrades are distinguishable—e.g., bump the Chart.yaml
`version` from 0.1.0 to at least 0.2.0 (for pre-1.0 minor bump) or to a major
version if you treat it as 1.x, commit the updated Chart.yaml `version` to
reflect the breaking subchart change.
In `@deploy/helm/grimmory/templates/deployment.yaml`:
- Around line 69-77: The env var DATABASE_PASSWORD currently references a
hardcoded secret key "mariadb-password" which is incompatible with the
CloudPirates MariaDB chart default; update the secretKeyRef key to use the
MariaDB chart's user password key instead (use "user-password" as the default)
and honor any configured override in the chart values. Concretely, replace the
static key: mariadb-password with a templated expression that defaults to
"user-password" but uses .Values.mariadb.auth.secretKeys.userPasswordKey when
provided (and keep the existing logic around .Values.mariadb.auth.existingSecret
and the release-named secret unchanged).
---
Nitpick comments:
In `@deploy/helm/grimmory/templates/deployment.yaml`:
- Around line 39-44: The init-container waiting loop uses
.Values.mariadb.service.port directly so if the mariadb subchart is disabled the
port becomes empty and the nc check and the rendered DATABASE_URL end up with a
trailing colon; update the template to use a defensive default port (3306)
wherever .Values.mariadb.service.port is referenced (e.g., in the init-container
nc until loop and the DATABASE_URL rendering) by applying Helm's default/ternary
operator to fall back to 3306 (keep the same variable names like
.Values.mariadb.service.port and .Release.Name so the change is minimal and
localized).
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository YAML (base), Organization UI (inherited)
Review profile: CHILL
Plan: Pro
Run ID: 8cd532b4-9e7c-4fe1-b7a3-e5dcec98841c
📒 Files selected for processing (3)
deploy/helm/grimmory/Chart.yamldeploy/helm/grimmory/templates/deployment.yamldeploy/helm/grimmory/values.yaml
📜 Review details
🔇 Additional comments (1)
deploy/helm/grimmory/values.yaml (1)
7-8: Image tag12.2.2is valid and properly configured.The mariadb tag
12.2.2exists on Docker Hub (active, last updated 2026-04-15) and is supported by CloudPirates mariadb chart 0.16.x. The configuration structure usingmariadb.image.tagis correct for this chart version. No compatibility issues or deployment failures are expected.
|
This is what SonarCloud is complaining about. Dunno enough about Helm to judge whether it's feedback good or not.
|
Yeah, it's good feedback but unrelated to this PR. |
Description
This PR updates the helm charts to the current version of Grimmory.
It also updates the subchart of MariaDB from the Bitnami chart to the one maintained by CloudPirates.
Linked Issue: Fixes #872
Changes
appVersiontov3.0.0(the latest release) so the chart pullsgrimmory-tools/grimmory:v3.0.0Deploymenttemplate and defaultvalues.yamlto use the values structure of CloudPirate's chart.Summary by CodeRabbit