Conversation
ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (37)
📝 WalkthroughWalkthroughFlame Hub and Flame Node Helm charts migrate object storage from MinIO to SeaweedFS, add shared PostgreSQL and Harbor Secret wiring, enable Authup provisioning, and introduce SeaweedFS admin Gateway exposure. Node hostname handling and message-broker actuator exposure are also updated. ChangesFlame Hub platform wiring
Flame Node storage and Gateway updates
Estimated code review effort: 5 (Critical) | ~120 minutes Possibly related PRs
Suggested labels: Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 6
🧹 Nitpick comments (5)
charts/third-party/authup/templates/deployment.yaml (3)
94-117: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueCompute the DB secret name once.
$dbUserSecret(Line 95) and$dbSecret(Line 109) evaluate the identicaltplexpression; hoist a single variable above theenv:entries.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@charts/third-party/authup/templates/deployment.yaml` around lines 94 - 117, Compute the database secret name once before the DB_USERNAME and DB_PASSWORD environment entries, then reuse that variable in both conditional branches. Remove the duplicate tpl evaluation and preserve the existing secretKeyRef and direct-value behavior.
141-152: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winNo rollout trigger when the provisioning ConfigMap changes.
Provisioning is applied at boot, so editing the ConfigMap (or the parent's
provisioning-configmap.yaml) has no effect until the pod is restarted manually. Achecksum/provisioningpod annotation keyed on the rendered content (or on the ConfigMap lookup whenexistingConfigMapis used) makes upgrades self-applying.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@charts/third-party/authup/templates/deployment.yaml` around lines 141 - 152, Add a pod-template annotation named checksum/provisioning in the deployment template, deriving its value from the rendered provisioning ConfigMap content or the referenced existing ConfigMap when provisioning.enabled is true. Ensure changes to provisioning-configmap.yaml or the configured existingConfigMap update the checksum and trigger a pod rollout, while preserving the current volumeMounts and volumes behavior.
25-25: 🩺 Stability & Availability | 🔵 Trivial | ⚡ Quick winPort stays hardcoded while the host became configurable.
database.hostis now templated/required, but the readiness probe still assumes 5432. Worth addingdatabase.port(defaulting to 5432) and using it here and inDB_PORT, otherwise a non-default PostgreSQL port makes this init container block forever.♻️ Suggested change
- 'until nc -z -v -w30 {{ tpl (required "database.host is required (set authup.database.host in the parent chart)" .Values.database.host) $ }} 5432; do echo "Waiting for db..."; sleep 5; done' + 'until nc -z -v -w30 {{ tpl (required "database.host is required (set authup.database.host in the parent chart)" .Values.database.host) $ }} {{ .Values.database.port | default 5432 }}; do echo "Waiting for db..."; sleep 5; done'🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@charts/third-party/authup/templates/deployment.yaml` at line 25, Add a configurable database.port value with a default of 5432, then update the deployment readiness command and DB_PORT environment variable to use the templated database.port value alongside database.host. Preserve the existing required-host validation and default behavior for PostgreSQL port 5432.charts/flame-hub/values.yaml (1)
56-70: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winConsider a render-time guard for the duplicated literals.
The comments document that
harbor.database.external.host/existingSecretandharbor.expose.clusterIP.namemust stay in sync withglobal.flameHub.postgresql.*, but nothing enforces it — a release that setsglobal.flameHub.postgresql.existingSecretwithout editing the Harbor literals silently points Harbor at a non-existent Secret. A small helper usingfailwhenharbor.database.external.host != global.flameHub.postgresql.hostorharbor.database.external.existingSecretdiffers from the effective pg secret name would turn a runtime CrashLoop into ahelm templateerror.Also applies to: 517-527
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@charts/flame-hub/values.yaml` around lines 56 - 70, Add a Helm render-time validation helper that fails when harbor.database.external.host differs from global.flameHub.postgresql.host, when harbor.database.external.existingSecret differs from the effective PostgreSQL secret name (existingSecret when set, otherwise secretName), or when harbor.expose.clusterIP.name is out of sync with the corresponding global PostgreSQL configuration. Invoke the helper during chart rendering so helm template reports the mismatch before workloads are deployed..gitignore (1)
14-15: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winOverly broad gitignore pattern.
node*.yamlmatches any file at any depth whose basename starts with "node", not just the intended local override file (e.g. it would also match a future legitimately-named chart file likecharts/flame-node/node-foo.yaml). Consider scoping it more precisely, e.g. to a specific filename or a dedicatedlocal/directory.♻️ Suggested narrower pattern
-node*.yaml +/node-*.local.yaml🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.gitignore around lines 14 - 15, Replace the overly broad node*.yaml entry in .gitignore with a narrowly scoped pattern matching only the intended local override filename or dedicated local directory, while preserving the existing .claude ignore rule.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@charts/flame-hub/templates/_helpers.tpl`:
- Around line 96-102: Update flameHub.seaweedfs.fullname to honor both
seaweedfs.fullnameOverride and the parent chart’s seaweedfs.fullnameOverride
before applying the existing generated-name logic. Update
flameHub.seaweedfs.s3Host to derive the -all-in-one hostname from a base name
truncated to the available 63-character budget. Add coverage for a 63-character
release name and for seaweedfs.fullnameOverride, verifying resource and parent
references remain aligned.
In `@charts/flame-hub/templates/authup/provisioning-configmap.yaml`:
- Around line 98-109: Add permission definitions for user_self_manage,
client_read, and client_update in the ConfigMap’s permissions block before the
roles section, matching the existing permission declaration structure. Keep the
steward role’s globalPermissions references unchanged so they resolve to the
newly declared permissions.
In `@charts/flame-hub/templates/postgresql/statefulset.yaml`:
- Around line 30-60: Align the PostgreSQL credentials used by the StatefulSet
with Harbor’s configured database user. Update the POSTGRES_USER source and both
pg_isready probes in the container specification to consistently use the shared
postgres username, or add validation/documentation enforcing that
harbor.database.external.username matches the Secret username; preserve the
existing POSTGRES_PASSWORD Secret reference.
In `@charts/flame-node/Chart.yaml`:
- Around line 50-52: Update the seaweedfs dependency in
charts/flame-node/Chart.yaml from 4.37.0 to 4.39.0, matching
flame-node-data-store/Chart.yaml and the existing vendored dependency version.
Add the corresponding charts/flame-node/charts/seaweedfs-4.39.0.tgz package so
the chart does not rely on build-time fetching.
In `@charts/flame-node/flame-node-data-store/values.yaml`:
- Around line 5-16: The blaze chart has no SeaweedFS dependency, so the scoped
global configuration in values.yaml is ineffective. Either add the required
SeaweedFS dependency to blaze/Chart.yaml so the seaweedfs settings propagate to
the grandchild chart, or remove the blaze.global.seaweedfs configuration block.
In `@charts/flame-node/values.yaml`:
- Around line 903-913: Update the ingress hostname documentation comment in the
values configuration to reference the actual host key used by
dataStore.seaweedfs.admin.ingress, replacing the mismatched hostname path while
leaving the configuration fields unchanged.
---
Nitpick comments:
In @.gitignore:
- Around line 14-15: Replace the overly broad node*.yaml entry in .gitignore
with a narrowly scoped pattern matching only the intended local override
filename or dedicated local directory, while preserving the existing .claude
ignore rule.
In `@charts/flame-hub/values.yaml`:
- Around line 56-70: Add a Helm render-time validation helper that fails when
harbor.database.external.host differs from global.flameHub.postgresql.host, when
harbor.database.external.existingSecret differs from the effective PostgreSQL
secret name (existingSecret when set, otherwise secretName), or when
harbor.expose.clusterIP.name is out of sync with the corresponding global
PostgreSQL configuration. Invoke the helper during chart rendering so helm
template reports the mismatch before workloads are deployed.
In `@charts/third-party/authup/templates/deployment.yaml`:
- Around line 94-117: Compute the database secret name once before the
DB_USERNAME and DB_PASSWORD environment entries, then reuse that variable in
both conditional branches. Remove the duplicate tpl evaluation and preserve the
existing secretKeyRef and direct-value behavior.
- Around line 141-152: Add a pod-template annotation named checksum/provisioning
in the deployment template, deriving its value from the rendered provisioning
ConfigMap content or the referenced existing ConfigMap when provisioning.enabled
is true. Ensure changes to provisioning-configmap.yaml or the configured
existingConfigMap update the checksum and trigger a pod rollout, while
preserving the current volumeMounts and volumes behavior.
- Line 25: Add a configurable database.port value with a default of 5432, then
update the deployment readiness command and DB_PORT environment variable to use
the templated database.port value alongside database.host. Preserve the existing
required-host validation and default behavior for PostgreSQL port 5432.
🪄 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: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 871e9e2e-6500-4d1c-86ac-8b8eb8d1b573
📒 Files selected for processing (37)
.gitignorecharts/flame-hub/Chart.yamlcharts/flame-hub/README.mdcharts/flame-hub/templates/_helpers.tplcharts/flame-hub/templates/_urls.tplcharts/flame-hub/templates/authup/provisioning-configmap.yamlcharts/flame-hub/templates/credentials-secret.yamlcharts/flame-hub/templates/harbor/ingress.yamlcharts/flame-hub/templates/harbor/secret.yamlcharts/flame-hub/templates/postgresql/configmap-init.yamlcharts/flame-hub/templates/postgresql/secret.yamlcharts/flame-hub/templates/postgresql/service.yamlcharts/flame-hub/templates/postgresql/statefulset.yamlcharts/flame-hub/templates/server-core-worker/deployment.yamlcharts/flame-hub/templates/server-core/deployment.yamlcharts/flame-hub/templates/server-messenger/deployment.yamlcharts/flame-hub/templates/server-storage/deployment.yamlcharts/flame-hub/templates/server-telemetry/deployment.yamlcharts/flame-hub/values.yamlcharts/flame-node/Chart.yamlcharts/flame-node/flame-node-data-store/Chart.yamlcharts/flame-node/flame-node-data-store/charts/minio-5.4.0.tgzcharts/flame-node/flame-node-data-store/charts/seaweedfs-4.39.0.tgzcharts/flame-node/flame-node-data-store/values.yamlcharts/flame-node/templates/_helpers.tplcharts/flame-node/templates/data-store/httproute.yamlcharts/flame-node/templates/gateway-client-settings-policy.yamlcharts/flame-node/templates/gateway.yamlcharts/flame-node/templates/message-broker/deployment.ymlcharts/flame-node/templates/message-broker/service.ymlcharts/flame-node/templates/secret.yamlcharts/flame-node/templates/storage-service/deployment.yamlcharts/flame-node/values.yamlcharts/flame-node/values_min.yamlcharts/third-party/authup/templates/configmap-provisioning.yamlcharts/third-party/authup/templates/deployment.yamlcharts/third-party/authup/values.yaml
There was a problem hiding this comment.
Caution
Inline review comments failed to post. This is likely due to GitHub's internal server error or limits when posting large numbers of comments. If you are seeing this consistently it is likely a permissions issue. Please check "Moderation" -> "Code review limits" under your organization settings.
Actionable comments posted: 6
🧹 Nitpick comments (5)
charts/third-party/authup/templates/deployment.yaml (3)
94-117: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueCompute the DB secret name once.
$dbUserSecret(Line 95) and$dbSecret(Line 109) evaluate the identicaltplexpression; hoist a single variable above theenv:entries.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@charts/third-party/authup/templates/deployment.yaml` around lines 94 - 117, Compute the database secret name once before the DB_USERNAME and DB_PASSWORD environment entries, then reuse that variable in both conditional branches. Remove the duplicate tpl evaluation and preserve the existing secretKeyRef and direct-value behavior.
141-152: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winNo rollout trigger when the provisioning ConfigMap changes.
Provisioning is applied at boot, so editing the ConfigMap (or the parent's
provisioning-configmap.yaml) has no effect until the pod is restarted manually. Achecksum/provisioningpod annotation keyed on the rendered content (or on the ConfigMap lookup whenexistingConfigMapis used) makes upgrades self-applying.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@charts/third-party/authup/templates/deployment.yaml` around lines 141 - 152, Add a pod-template annotation named checksum/provisioning in the deployment template, deriving its value from the rendered provisioning ConfigMap content or the referenced existing ConfigMap when provisioning.enabled is true. Ensure changes to provisioning-configmap.yaml or the configured existingConfigMap update the checksum and trigger a pod rollout, while preserving the current volumeMounts and volumes behavior.
25-25: 🩺 Stability & Availability | 🔵 Trivial | ⚡ Quick winPort stays hardcoded while the host became configurable.
database.hostis now templated/required, but the readiness probe still assumes 5432. Worth addingdatabase.port(defaulting to 5432) and using it here and inDB_PORT, otherwise a non-default PostgreSQL port makes this init container block forever.♻️ Suggested change
- 'until nc -z -v -w30 {{ tpl (required "database.host is required (set authup.database.host in the parent chart)" .Values.database.host) $ }} 5432; do echo "Waiting for db..."; sleep 5; done' + 'until nc -z -v -w30 {{ tpl (required "database.host is required (set authup.database.host in the parent chart)" .Values.database.host) $ }} {{ .Values.database.port | default 5432 }}; do echo "Waiting for db..."; sleep 5; done'🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@charts/third-party/authup/templates/deployment.yaml` at line 25, Add a configurable database.port value with a default of 5432, then update the deployment readiness command and DB_PORT environment variable to use the templated database.port value alongside database.host. Preserve the existing required-host validation and default behavior for PostgreSQL port 5432.charts/flame-hub/values.yaml (1)
56-70: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winConsider a render-time guard for the duplicated literals.
The comments document that
harbor.database.external.host/existingSecretandharbor.expose.clusterIP.namemust stay in sync withglobal.flameHub.postgresql.*, but nothing enforces it — a release that setsglobal.flameHub.postgresql.existingSecretwithout editing the Harbor literals silently points Harbor at a non-existent Secret. A small helper usingfailwhenharbor.database.external.host != global.flameHub.postgresql.hostorharbor.database.external.existingSecretdiffers from the effective pg secret name would turn a runtime CrashLoop into ahelm templateerror.Also applies to: 517-527
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@charts/flame-hub/values.yaml` around lines 56 - 70, Add a Helm render-time validation helper that fails when harbor.database.external.host differs from global.flameHub.postgresql.host, when harbor.database.external.existingSecret differs from the effective PostgreSQL secret name (existingSecret when set, otherwise secretName), or when harbor.expose.clusterIP.name is out of sync with the corresponding global PostgreSQL configuration. Invoke the helper during chart rendering so helm template reports the mismatch before workloads are deployed..gitignore (1)
14-15: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winOverly broad gitignore pattern.
node*.yamlmatches any file at any depth whose basename starts with "node", not just the intended local override file (e.g. it would also match a future legitimately-named chart file likecharts/flame-node/node-foo.yaml). Consider scoping it more precisely, e.g. to a specific filename or a dedicatedlocal/directory.♻️ Suggested narrower pattern
-node*.yaml +/node-*.local.yaml🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.gitignore around lines 14 - 15, Replace the overly broad node*.yaml entry in .gitignore with a narrowly scoped pattern matching only the intended local override filename or dedicated local directory, while preserving the existing .claude ignore rule.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@charts/flame-hub/templates/_helpers.tpl`:
- Around line 96-102: Update flameHub.seaweedfs.fullname to honor both
seaweedfs.fullnameOverride and the parent chart’s seaweedfs.fullnameOverride
before applying the existing generated-name logic. Update
flameHub.seaweedfs.s3Host to derive the -all-in-one hostname from a base name
truncated to the available 63-character budget. Add coverage for a 63-character
release name and for seaweedfs.fullnameOverride, verifying resource and parent
references remain aligned.
In `@charts/flame-hub/templates/authup/provisioning-configmap.yaml`:
- Around line 98-109: Add permission definitions for user_self_manage,
client_read, and client_update in the ConfigMap’s permissions block before the
roles section, matching the existing permission declaration structure. Keep the
steward role’s globalPermissions references unchanged so they resolve to the
newly declared permissions.
In `@charts/flame-hub/templates/postgresql/statefulset.yaml`:
- Around line 30-60: Align the PostgreSQL credentials used by the StatefulSet
with Harbor’s configured database user. Update the POSTGRES_USER source and both
pg_isready probes in the container specification to consistently use the shared
postgres username, or add validation/documentation enforcing that
harbor.database.external.username matches the Secret username; preserve the
existing POSTGRES_PASSWORD Secret reference.
In `@charts/flame-node/Chart.yaml`:
- Around line 50-52: Update the seaweedfs dependency in
charts/flame-node/Chart.yaml from 4.37.0 to 4.39.0, matching
flame-node-data-store/Chart.yaml and the existing vendored dependency version.
Add the corresponding charts/flame-node/charts/seaweedfs-4.39.0.tgz package so
the chart does not rely on build-time fetching.
In `@charts/flame-node/flame-node-data-store/values.yaml`:
- Around line 5-16: The blaze chart has no SeaweedFS dependency, so the scoped
global configuration in values.yaml is ineffective. Either add the required
SeaweedFS dependency to blaze/Chart.yaml so the seaweedfs settings propagate to
the grandchild chart, or remove the blaze.global.seaweedfs configuration block.
In `@charts/flame-node/values.yaml`:
- Around line 903-913: Update the ingress hostname documentation comment in the
values configuration to reference the actual host key used by
dataStore.seaweedfs.admin.ingress, replacing the mismatched hostname path while
leaving the configuration fields unchanged.
---
Nitpick comments:
In @.gitignore:
- Around line 14-15: Replace the overly broad node*.yaml entry in .gitignore
with a narrowly scoped pattern matching only the intended local override
filename or dedicated local directory, while preserving the existing .claude
ignore rule.
In `@charts/flame-hub/values.yaml`:
- Around line 56-70: Add a Helm render-time validation helper that fails when
harbor.database.external.host differs from global.flameHub.postgresql.host, when
harbor.database.external.existingSecret differs from the effective PostgreSQL
secret name (existingSecret when set, otherwise secretName), or when
harbor.expose.clusterIP.name is out of sync with the corresponding global
PostgreSQL configuration. Invoke the helper during chart rendering so helm
template reports the mismatch before workloads are deployed.
In `@charts/third-party/authup/templates/deployment.yaml`:
- Around line 94-117: Compute the database secret name once before the
DB_USERNAME and DB_PASSWORD environment entries, then reuse that variable in
both conditional branches. Remove the duplicate tpl evaluation and preserve the
existing secretKeyRef and direct-value behavior.
- Around line 141-152: Add a pod-template annotation named checksum/provisioning
in the deployment template, deriving its value from the rendered provisioning
ConfigMap content or the referenced existing ConfigMap when provisioning.enabled
is true. Ensure changes to provisioning-configmap.yaml or the configured
existingConfigMap update the checksum and trigger a pod rollout, while
preserving the current volumeMounts and volumes behavior.
- Line 25: Add a configurable database.port value with a default of 5432, then
update the deployment readiness command and DB_PORT environment variable to use
the templated database.port value alongside database.host. Preserve the existing
required-host validation and default behavior for PostgreSQL port 5432.
🪄 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: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 871e9e2e-6500-4d1c-86ac-8b8eb8d1b573
📒 Files selected for processing (37)
.gitignorecharts/flame-hub/Chart.yamlcharts/flame-hub/README.mdcharts/flame-hub/templates/_helpers.tplcharts/flame-hub/templates/_urls.tplcharts/flame-hub/templates/authup/provisioning-configmap.yamlcharts/flame-hub/templates/credentials-secret.yamlcharts/flame-hub/templates/harbor/ingress.yamlcharts/flame-hub/templates/harbor/secret.yamlcharts/flame-hub/templates/postgresql/configmap-init.yamlcharts/flame-hub/templates/postgresql/secret.yamlcharts/flame-hub/templates/postgresql/service.yamlcharts/flame-hub/templates/postgresql/statefulset.yamlcharts/flame-hub/templates/server-core-worker/deployment.yamlcharts/flame-hub/templates/server-core/deployment.yamlcharts/flame-hub/templates/server-messenger/deployment.yamlcharts/flame-hub/templates/server-storage/deployment.yamlcharts/flame-hub/templates/server-telemetry/deployment.yamlcharts/flame-hub/values.yamlcharts/flame-node/Chart.yamlcharts/flame-node/flame-node-data-store/Chart.yamlcharts/flame-node/flame-node-data-store/charts/minio-5.4.0.tgzcharts/flame-node/flame-node-data-store/charts/seaweedfs-4.39.0.tgzcharts/flame-node/flame-node-data-store/values.yamlcharts/flame-node/templates/_helpers.tplcharts/flame-node/templates/data-store/httproute.yamlcharts/flame-node/templates/gateway-client-settings-policy.yamlcharts/flame-node/templates/gateway.yamlcharts/flame-node/templates/message-broker/deployment.ymlcharts/flame-node/templates/message-broker/service.ymlcharts/flame-node/templates/secret.yamlcharts/flame-node/templates/storage-service/deployment.yamlcharts/flame-node/values.yamlcharts/flame-node/values_min.yamlcharts/third-party/authup/templates/configmap-provisioning.yamlcharts/third-party/authup/templates/deployment.yamlcharts/third-party/authup/values.yaml
🛑 Comments failed to post (6)
charts/flame-hub/templates/_helpers.tpl (1)
96-102: 🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash set -euo pipefail echo "== locate helpers and referenced templates ==" git ls-files | rg 'charts/flame-hub/templates|seaweedfs|all-in-one|s3Host|fullnameOverride|flameHub\.seaweedfs' || true echo echo "== relevant _helpers.tpl sections ==" sed -n '1,180p' charts/flame-hub/templates/_helpers.tpl echo echo "== usages of flameHub.seaweedfs.fullname and s3Host ==" rg -n 'flameHub\.seaweedfs\.fullname|s3Host|fullnameOverride|service\.s3\.host|secret' charts/flame-hub/templates -S || true echo echo "== flame-hub Chart.yaml dependency/version context ==" sed -n '1,220p' charts/flame-hub/Chart.yaml || true echo echo "== installed/seaweedfs chart helpers if present in repo ==" for f in $(git ls-files | rg 'seaweedfs/.*/templates/.*/_helpers\.tpl|seaweedfs/.*_helpers\.tpl$|seaweedfs.*shared/_helpers\.tpl$'); do echo "-- $f" wc -l "$f" sed -n '1,220p' "$f" | rg -n '`@name`|seaweedfs\.fullname|fullnameOverride|trunc|all-in-one|define|name|fullname' || true doneRepository: PrivateAIM/helm
Length of output: 19319
🏁 Script executed:
#!/bin/bash set -euo pipefail echo "== seaweedfs packaged chart metadata and helper files ==" tar -tzf charts/flame-node/flame-node-data-store/charts/seaweedfs-4.39.0.tgz | rg '^seaweedfs/(Chart\.yaml|values\.yaml|templates/.*_helpers\.tpl|templates/s(erviceall|tatefulsetall|ecret)\.yaml|templates/shared/_helpers\.tpl)$' || true echo echo "== unpack selected sealed-seaweedfs files ==" tmp="$(mktemp -d)" tar -xzf charts/flame-node/flame-node-data-store/charts/seaweedfs-4.39.0.tgz -C "$tmp" for f in "$tmp"/seaweedfs/Chart.yaml "$tmp"/seaweedfs/values.yaml "$tmp"/seaweedfs/templates/shared/_helpers.tpl "$tmp"/seaweedfs/templates/s3secret.yaml; do if [ -f "$f" ]; then echo "-- $(realpath --relative-to "$tmp"/seaweedfs "$f")" wc -l "$f" sed -n '1,220p' "$f" | rg -n 'fullname|nameOverride|fullnameOverride|s3-secret|all-in-one|define|resource|service|secret' || true fi done echo echo "== relevant template sections ==" sed -n '1,220p' "$tmp"/seaweedfs/templates/s3secret.yaml echo sed -n '1,140p' "$tmp"/seaweedfs/templates/shared/_helpers.tpl echo echo "== deterministic behavior probe for helper input/output shapes ==" python3 - <<'PY' MAX = 63 def current_seaweedfs_fullname(release_name, name_override): name = "seaweedfs" if name_override is None else name_override if name in release_name: base = release_name else: base = f"{release_name}-{name}" return base[:MAX].rstrip("-") def current_s3_host(release_name, name_override): base = current_seaweedfs_fullname(release_name, name_override) return f"{base}-all-in-one" cases = [ ("very-long-release-this-is-the-longest-release-name-possible", None), ("very-long-release-this-is-the-longest-release-name-possible", "something-else"), ("short", None), ] for rel, override in cases: name = current_seaweedfs_fullname(rel, override) s3 = current_s3_host(rel, override) print({"release": rel, "override": override, "fullname": name, "s3host": s3, "fullname_len": len(name), "s3host_len": len(s3)}) PYRepository: PrivateAIM/helm
Length of output: 2523
🏁 Script executed:
#!/bin/bash set -euo pipefail tmp="$(mktemp -d)" tar -xzf charts/flame-node/flame-node-data-store/charts/seaweedfs-4.39.0.tgz -C "$tmp" echo "== seaweedfs templates containing S3 service/secret/all-in-one names ==" tar -tzf charts/flame-node/flame-node-data-store/charts/seaweedfs-4.39.0.tgz | rg '^seaweedfs/templates/' | sort echo for f in "$tmp"/seaweedfs/templates/service.yaml "$tmp"/seaweedfs/templates/all-in-one.yaml "$tmp"/seaweedfs/templates/secret.yaml "$tmp"/seaweedfs/templates/_helpers.tpl "$tmp"/seaweedfs/templates/shared/_helpers.tpl; do [ -f "$f" ] || continue echo "-- $(grep -n '`@name`\|fullnameOverride\|nameOverride\|all-in-one\|s3-secret\|Service\|Secret\|metadata:' "$f" | head -120 || true)" echo "Lengths:" wc -l "$f" echo "-- $f" rg -n 'nameOverride|fullnameOverride|all-in-one|s3-secret|define|metadata|name:' "$f" -C 3 || true echo done echo echo "== deterministic behavior probe ==" python3 - <<'PY' MAX = 63 def current_helper(release_name, name_override): name = "seaweedfs" if name_override is None else name_override if name in release_name: base = release_name else: base = release_name + "-" + name return base[:MAX].rstrip("-") def current_s3_host(release_name, name_override): return current_helper(release_name, name_override) + "-all-in-one" cases = [ ("very-long-release-this-is-the-longest-release-name-possible", None), ("very-long-release-this-is-the-longest-release-name-possible", "something-else"), ("short", None), ] for rel, override in cases: full = current_helper(rel, override) host = current_s3_host(rel, override) print({"release": rel, "override": override, "fullname": full, "s3host": host, "fullname_len": len(full), "s3host_len": len(host), "over_63": len(host) > 63}) PYRepository: PrivateAIM/helm
Length of output: 15633
Align SeaweedFS resource names with its helpers.
flameHub.seaweedfs.fullnameshould honorseaweedfs.fullnameOverrideand the parent chart’sseaweedfs.fullnameOverride;flameHub.seaweedfs.s3Hostshould build-all-in-onefrom the base name’s character budget so it cannot exceed 63 characters. This keeps parent references aligned withseaweedfs-4.39.0service/secret names; add cover for a 63-character release name and aseaweedfs.fullnameOverride.Also applies to lines 119-129.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@charts/flame-hub/templates/_helpers.tpl` around lines 96 - 102, Update flameHub.seaweedfs.fullname to honor both seaweedfs.fullnameOverride and the parent chart’s seaweedfs.fullnameOverride before applying the existing generated-name logic. Update flameHub.seaweedfs.s3Host to derive the -all-in-one hostname from a base name truncated to the available 63-character budget. Add coverage for a 63-character release name and for seaweedfs.fullnameOverride, verifying resource and parent references remain aligned.charts/flame-hub/templates/authup/provisioning-configmap.yaml (1)
98-109: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🌐 Web query:
authup server-core built-in permissions user_self_manage client_read💡 Result:
In the Authup ecosystem, permissions are managed through a system of built-in and custom policies [1]. Permissions such as user_self_manage and client_read are defined within the Authup server-core service to control access to specific resources [2][3]. Built-in permissions in Authup are created and maintained automatically by the system on startup and are marked as built_in, meaning they cannot be modified or deleted via the API [1]. These permissions are often used alongside policies to enforce security restrictions, such as realm scoping or identity-based access [1]. Regarding the specific identifiers mentioned: user_self_manage: This is typically associated with the ability for a user to manage their own profile or account information [2]. client_read: This permission allows an actor to read client-related data [4]. In Authup, access to resources—including checking if an identity has a specific permission—is governed by the core access control system, which often integrates with API endpoints that return these permission entities [1][2]. It should be noted that Authup uses a permission-based gating system for its API relations [5]. For example, certain operations may require specific permissions (like PERMISSION_READ) to access related entities, and failing to hold the necessary permission can result in relations being silently stripped from API responses [5]. Administrators can assign these permissions globally or to specific realms and clients during the provisioning process [6].
Citations:
- 1: https://authup.org/guide/user/permissions-and-policies.html
- 2: https://authup.org/guide/development/api-examples.html
- 3: https://github.com/authup/authup
- 4: https://docs.btx.banqup.com/docs/workspace/clients/get-permissions
- 5: PrivateAIM/hub#1777
- 6: https://authup.org/guide/deployment/provisioning.html
🌐 Web query:
Authup built-in permissions listing user_self_manage client_read💡 Result:
In the Authup authentication and authorization system, permissions are independent entities that represent the ability to perform a specific action [1]. Authup does not have a static, hard-coded list of "built-in" permissions like user_self_manage or client_read in the sense of reserved system-level keywords [1]. Instead, Authup allows users to define custom permissions to suit their system's requirements [1][2]. Permissions are managed through the system as resources, and they exist independently of roles and users [1]. You can create, retrieve, update, and delete permissions via the Authup API [2]. If a permission named user_self_manage or client_read exists in your implementation, it has been specifically created within your Authup instance (likely to represent actions such as a user managing their own profile or a client reading resource data) [2]. To verify or list the permissions currently defined in your Authup system, you can use the following API request [2]: GET /permissions Authorization: Bearer <your_access_token> Because Authup uses an allow-by-default model, simply defining a permission name does not restrict it; restrictions are instead enforced by policies attached to those permissions [1]. Policies can be bundled with these permissions to define the specific conditions under which they are granted [1].
Citations:
- 1: https://authup.org/guide/user/permissions-and-policies.html
- 2: https://authup.org/guide/development/api-examples.html
🌐 Web query:
site:github.com/authup/authup user_self_manage client_read💡 Result:
The terms user_self_manage and client_read appear to be permission scopes or identifiers associated with the Authup authentication and authorization system [1][2]. While Authup is a documented open-source project that utilizes these types of access-management strategies—including claim-based and attribute-based authorization—specific public documentation detailing the exact functional definitions of these two specific strings is not present in the provided search results [1]. Authup is designed to support standard protocols like OAuth 2.0 and OpenID Connect, which commonly use such scopes to define granular access levels for users and clients [1].
Citations:
- 1: https://github.com/authup/authup/blob/master/CITATION.cff
- 2: https://github.com/authup/authup/discussions
🌐 Web query:
github authup repository permissions.go "user_self_manage" "client_read"💡 Result:
Authup is an authentication and authorization framework that supports declarative, isomorphic permission management [1][2]. While you specifically mentioned permissions.go and identifiers like user_self_manage or client_read, it is important to note that the Authup core repository is primarily implemented in TypeScript and JavaScript, not Go [1]. In Authup, permissions are central concepts used to control access [3]. They can be managed via the REST API or declared in configuration files [4][2]. Examples of common operations involve interacting with a Permission resource, such as fetching, creating, updating, or deleting specific permissions (e.g., via HTTP requests to /permissions) [5]. Regarding the specific identifiers: 1. User Permissions: Authup supports managing user-specific permissions (e.g., via user_read, profile_edit) [5][6]. While user_self_manage is not explicitly documented as a default built-in permission name, Authup allows for the creation of custom permissions that can be assigned to users or roles to facilitate self-management workflows [3][5]. 2. Client Permissions: Authup differentiates between permissions for clients and users [6]. Permissions like client_read or client_add are standard patterns for controlling access to client-related management APIs [6][7]. 3. Implementation: Logic related to permission evaluation, such as the
permission-bindingevaluator, is found within the TypeScript/JavaScript server core (e.g., apps/server-core/src/core/security/policy/evaluator.ts) [8]. If you are encountering a file named permissions.go in a repository related to Authup, it is likely part of a specific language-specific plugin, integration, or a third-party implementation, as the primary Authup framework is built using TypeScript [1][7][9].Citations:
- 1: https://github.com/authup/authup
- 2: https://authup.org/
- 3: https://authup.org/guide/user/permissions-and-policies.html
- 4: https://authup.org/getting-started/
- 5: https://authup.org/guide/development/api-examples.html
- 6: https://authup.org/sdks/javascript/core-http-kit/client.html
- 7: https://github.com/authup/python-sdk
- 8: authup/authup@4c01f95
- 9: https://github.com/authup/python-sdk/
🌐 Web query:
"authup" "builtinPermissions" "user_self_manage"💡 Result:
In Authup, user_self_manage is not listed as a standard built-in permission [1][2]. Authup utilizes a system of built-in policies (such as system.default, system.identity, and system.permission-binding) and permissions to manage access [1]. While Authup provides several built-in permissions (e.g., user_read, role_edit) [2], custom permissions are used to implement specific functionality like allowing users to manage their own profiles [2]. You can implement user self-management by creating a custom permission (for example, named profile_edit) [2]. This custom permission allows for the necessary granular control and can be assigned to users or roles via the Authup API [2][3]. Custom permissions are identified by having their built_in property set to false [2]. To create such a permission, you would interact with the Permission API (e.g., via a POST request) [2]. Once created, you can assign it to the relevant user or role to grant them the authority to manage their own information [2][3].
Citations:
- 1: https://authup.org/guide/user/permissions-and-policies.html
- 2: https://authup.org/guide/development/api-examples.html
- 3: https://authup.org/sdks/javascript/core-http-kit/client.html
🏁 Script executed:
#!/bin/bash set -euo pipefail echo "Relevant Chart Files:" fd -a 'provisioning-configmap.yaml|values.yaml|Chart.yaml' . | sed -n '1,80p' echo echo "Target file context:" target="$(fd 'provisioning-configmap.yaml' . | grep 'charts/flame-hub/templates/authup/provisioning-configmap.yaml' | head -n 1 || true)" if [ -n "${target:-}" ]; then nl -ba "$target" | sed -n '1,150p' fi echo echo "Authup references in repo:" rg -n "authup|permissions:|globalPermissions:|user_self_manage|client_read|client_update" . || trueRepository: PrivateAIM/helm
Length of output: 1033
🏁 Script executed:
#!/bin/bash set -euo pipefail echo "Chart file versions:" sed -n '1,80p' charts/flame-hub/Chart.yaml sed -n '1,120p' charts/third-party/authup/Chart.yaml sed -n '1,120p' charts/flame-hub/values.yaml | rg -n "authup|chart|repository|tag|version" -C 2 || true echo echo "Target provisioning configmap around referenced lines:" awk 'NR>=1 NR<=140 {printf "%6d:%s\n", NR, $0}' charts/flame-hub/templates/authup/provisioning-configmap.yaml echo echo "Target provisioning configmap permissions/authup blocks:" awk '/permissions:|globalPermissions:|user_self_manage|client_read|client_update/ {start=NR-8; end=NR+20; next} /^$/ && NR>end {exit} if (NR>=start && NR<=end) {printf "%6d:%s\n", NR, $0}' charts/flame-hub/templates/authup/provisioning-configmap.yaml echo echo "All repo references:" rg -n "authup|user_self_manage|client_read|client_update|globalPermissionsRealmScope|provisioning-configmap" . || trueRepository: PrivateAIM/helm
Length of output: 3810
🏁 Script executed:
#!/bin/bash set -euo pipefail echo "Target provisioning configmap lines 1-160:" awk 'NR>=1 && NR<=160 {printf "%6d:%s\n", NR, $0}' charts/flame-hub/templates/authup/provisioning-configmap.yaml echo echo "All repo references:" rg -n "authup|user_self_manage|client_read|client_update|globalPermissionsRealmScope|provisioning-configmap" . || true echo echo "Authup third-party chart values:" awk 'NR>=1 && NR<=220 {printf "%6d:%s\n", NR, $0}' charts/third-party/authup/values.yaml echo echo "Lockfile version pins:" if [ -f charts/flame-hub/Chart.lock ]; then awk 'NR>=1 && NR<=80 {printf "%6d:%s\n", NR, $0}' charts/flame-hub/Chart.lock; fiRepository: PrivateAIM/helm
Length of output: 25682
🌐 Web query:
github authup authup locter FileResourcePermissionRelation schema globalPermissionsRealmScope💡 Result:
Based on current authoritative technical documentation and repository analysis as of July 30, 2026, the terms FileResourcePermissionRelation and globalPermissionsRealmScope are not part of the Authup (https://authup.org) project architecture [1][2][3]. Authup is an open-source authentication and authorization system that utilizes OAuth2 and OpenID Connect protocols with support for multi-realm tenancy [3][4]. A comprehensive review of the Authup GitHub organization repositories—which include core server services, CLI tools, and adapters—confirms that these specific schema identifiers do not exist within the Authup codebase [2][3][5]. The terms provided appear to be associated with other software systems. For instance, code referencing "workspace_user_resource_permission" and similar patterns frequently appears in projects like MaxKB (a knowledge base application) [6][7], while "FileResource" and permission-related logic are common in content management frameworks such as Drupal [8][9]. Similarly, "global permissions" are a standard concept in enterprise platforms like Atlassian Jira, which utilizes specific API identifiers for managing global permissions [10][11].
Citations:
- 1: https://authup.org/guide/development/
- 2: https://github.com/authup
- 3: https://github.com/authup/authup
- 4: https://authup.org/
- 5: https://github.com/authup/adapters
- 6: https://github.com/1Panel-dev/MaxKB/blob/9ba11fda/apps/system_manage/serializers/user_resource_permission.py
- 7: https://github.com/1Panel-dev/MaxKB/blob/9ba11fda/apps/system_manage/migrations/0003_alter_workspaceuserresourcepermission_target.py
- 8: https://api.druphelp.com/api/drupal/core%21modules%21file%21tests%21src%21Functional%21Rest%21FileResourceTestBase.php/function/FileResourceTestBase%3A%3AsetUpAuthorization/8
- 9: https://api.druphelp.com/api/drupal/core%21modules%21file%21src%21Plugin%21rest%21resource%21FileUploadResource.php/function/FileUploadResource%3A%3Apermissions/9
- 10: https://developer.atlassian.com/platform/forge/manifest-reference/modules/jira-global-permission/
- 11: https://docs.atlassian.com/software/jira/docs/api/9.4.14/com/atlassian/jira/permission/GlobalPermissionKey.html
🌐 Web query:
Authup provisioning roles globalPermissions references permissions💡 Result:
In Authup, globalPermissions is a property used primarily in declarative provisioning to assign permissions with global scope to roles or entities [1]. These permissions are not bound to a specific realm, allowing them to be reusable across all realms [2]. When configuring roles during provisioning, the globalPermissions field accepts an array of permission names (strings) [1]. You can use the wildcard '' to assign all global permissions [1]. Additionally, you can control the scope and reach of these permissions using related fields [1]: - globalPermissionsExclude: Used to specify permissions to exclude when the '' wildcard is applied [1]. - globalPermissionsRealmScope: Defines the default realm scope (own, ownOrNull, or any) applied to each global permission junction entry [1]. - globalPermissionsRealmScopeOverrides: Allows for per-permission realm scope overrides, where keys represent the realm scope value and values are the lists of specific permissions [1]. Permissions in Authup are generally categorized as either global (realm_id = null) or realm-scoped [2]. The globalPermissions field specifically manages those that exist outside of any single realm context [2]. When evaluating these permissions, the system also considers associated policies and the specific realm scope (e.g., own, any) attached to the grant to determine the final access level [2].
Citations:
- 1: https://authup.org/guide/deployment/provisioning.html
- 2: https://authup.org/guide/user/permissions-and-policies.html
Declare the referenced permissions before assigning them in roles.
user_self_manage,client_read, andclient_updateare not declared in thepermissionsblock above. Add these permission definitions so the provisioned roles reference real permissions rather than unknown permission names.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@charts/flame-hub/templates/authup/provisioning-configmap.yaml` around lines 98 - 109, Add permission definitions for user_self_manage, client_read, and client_update in the ConfigMap’s permissions block before the roles section, matching the existing permission declaration structure. Keep the steward role’s globalPermissions references unchanged so they resolve to the newly declared permissions.charts/flame-hub/templates/postgresql/statefulset.yaml (1)
30-60: 🩺 Stability & Availability | 🟠 Major | ⚡ Quick win
Keep the PostgreSQL username aligned with Harbor.
POSTGRES_USERis taken from the effective Secret, which explicitly supports a configurableusername, while Harbor is configured with the literal database userpostgres. A custom username therefore initializes PostgreSQL with one role while Harbor connects as another and fails to start. The probes also use the unrelated values-based username. Enforcepostgresfor this shared database, or document/validate thatharbor.database.external.usernamemust match the Secret username. (raw.githubusercontent.com)🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@charts/flame-hub/templates/postgresql/statefulset.yaml` around lines 30 - 60, Align the PostgreSQL credentials used by the StatefulSet with Harbor’s configured database user. Update the POSTGRES_USER source and both pg_isready probes in the container specification to consistently use the shared postgres username, or add validation/documentation enforcing that harbor.database.external.username matches the Secret username; preserve the existing POSTGRES_PASSWORD Secret reference.charts/flame-node/Chart.yaml (1)
50-52: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash fd -e tgz . charts/flame-nodeRepository: PrivateAIM/helm
Length of output: 153
🏁 Script executed:
#!/bin/bash set -euo pipefail echo "Tracked files under charts/flame-node:" git ls-files charts/flame-node | sed -n '1,120p' echo echo "Locate Chart.yaml files with seaweedfs:" rg -n "name: seaweedfs|version: (4\.3[7-9]\.0|4\.)|repository: https://seaweedfs/github.com/seaweedfs/seaweedfs/helm|repository: https://seaweedfs.github.io/seaweedfs/helm" charts -g 'Chart.yaml' -g '*.yaml' echo echo "Git status summary:" git status --shortRepository: PrivateAIM/helm
Length of output: 4088
Align the SeaweedFS dependency version and vendored chart.
charts/flame-node/Chart.yamlpinsseaweedfsto4.37.0, whilecharts/flame-node/flame-node-data-store/Chart.yamland existing tracked vendored tarballs inchartsuse4.39.0. Align this pin to4.39.0if that is the intended version, and addcharts/flame-node/charts/seaweedfs-4.39.0.tgzinstead of relying on build-time fetch.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@charts/flame-node/Chart.yaml` around lines 50 - 52, Update the seaweedfs dependency in charts/flame-node/Chart.yaml from 4.37.0 to 4.39.0, matching flame-node-data-store/Chart.yaml and the existing vendored dependency version. Add the corresponding charts/flame-node/charts/seaweedfs-4.39.0.tgz package so the chart does not rely on build-time fetching.charts/flame-node/flame-node-data-store/values.yaml (1)
5-16: 🗄️ Data Integrity & Integration | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash cat charts/flame-node/flame-node-data-store/blaze/Chart.yaml 2>/dev/null || fd Chart.yaml charts/flame-node/flame-node-data-storeRepository: PrivateAIM/helm
Length of output: 1294
🏁 Script executed:
#!/bin/bash set -e printf '--- blaze Chart.yaml ---\n' wc -l charts/flame-node/flame-node-data-store/blaze/Chart.yaml sed -n '1,220p' charts/flame-node/flame-node-data-store/blaze/Chart.yaml printf '\n--- data store Chart.yaml ---\n' sed -n '1,220p' charts/flame-node/flame-node-data-store/Chart.yaml printf '\n--- values relevant snippets ---\n' sed -n '1,40p' charts/flame-node/flame-node-data-store/values.yaml printf '\n--- blaze templates dependency references ---\n' rg -n 'seaweedfs|blaze\.global|global\.seaweedfs|subchart|template|helmfile|Chart\.lock|dependencies' charts/flame-node/flame-node-data-store/blaze -S || trueRepository: PrivateAIM/helm
Length of output: 244
🏁 Script executed:
#!/bin/bash set -e echo '--- blaze Chart.yaml ---' wc -l charts/flame-node/flame-node-data-store/blaze/Chart.yaml sed -n '1,220p' charts/flame-node/flame-node-data-store/blaze/Chart.yaml echo '--- data store Chart.yaml ---' sed -n '1,220p' charts/flame-node/flame-node-data-store/Chart.yaml echo '--- values relevant snippets ---' sed -n '1,40p' charts/flame-node/flame-node-data-store/values.yaml echo '--- blaze templates dependency references ---' rg -n 'seaweedfs|blaze\.global|global\.seaweedfs|subchart|template|helmfile|Chart\.lock|dependencies' charts/flame-node/flame-node-data-store/blaze -S || true echo '--- parent data-store chart dependency context ---' rg -n '^dependencies:|name: seaweedfs|name: blaze|charts/flame-node/flame-node-data-store/values|seaweedfs:' charts/flame-node/flame-node-data-store -S || trueRepository: PrivateAIM/helm
Length of output: 4940
Add the
seaweedfsdependency underblazeor remove this scoped global.
blaze/Chart.yamldeclares no dependencies, soblaze.global.seaweedfshas no grandchild chart to render and the override will not take effect. Add the required SeaweedFS dependency intocharts/flame-node/flame-node-data-store/blaze/Chart.yaml, or remove thisblaze.global.seaweedfs:block.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@charts/flame-node/flame-node-data-store/values.yaml` around lines 5 - 16, The blaze chart has no SeaweedFS dependency, so the scoped global configuration in values.yaml is ineffective. Either add the required SeaweedFS dependency to blaze/Chart.yaml so the seaweedfs settings propagate to the grandchild chart, or remove the blaze.global.seaweedfs configuration block.charts/flame-node/values.yaml (1)
903-913: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
@paramname doesn't match the actual key (hostvs documentedhostname).The doc comment references
dataStore.seaweedfs.admin.ingress.hostname, but the actual field ishost. Tools like bitnami's readme-generator-for-helm validate@parampaths against real keys and error out on mismatches.📝 Suggested fix
ingress: enabled: false - ## `@param` dataStore.seaweedfs.admin.ingress.hostname Hostname for the admin panel. Must be set even if the same + ## `@param` dataStore.seaweedfs.admin.ingress.host Hostname for the admin panel. Must be set even if the same ## as .expose.hostname host:📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.## Expose the admin panel in the browser via the node Ingress API ingress: enabled: false ## `@param` dataStore.seaweedfs.admin.ingress.host Hostname for the admin panel. Must be set even if the same ## as .expose.hostname host: ## `@param` dataStore.seaweedfs.admin.ingress.path Base path the admin process serves from. path: "/seaweedfs" annotations: nginx.ingress.kubernetes.io/proxy-body-size: 500m🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@charts/flame-node/values.yaml` around lines 903 - 913, Update the ingress hostname documentation comment in the values configuration to reference the actual host key used by dataStore.seaweedfs.admin.ingress, replacing the mismatched hostname path while leaving the configuration fields unchanged.
Flux Statusℹ️ HelmRelease/pr-163-hub/hub Helm install succeeded for release pr-163-hub/hub.v1 with chart flame-hub@0.1.0+8229ed956de7 Metadata:
|
Summary by CodeRabbit