feat(charts): add br-spi-helm chart for the SPI rail#1608
Conversation
Backfills develop with the br-spi-helm chart, which landed on main via #1607 (direct-to-main) and was therefore absent from the develop prerelease channel. Scope is limited to charts/br-spi + its render fixture; the pre-existing main/develop drift in other charts is untouched. Claude-Session: https://claude.ai/code/session_012fNphWnucMKd84KskVFgvz Signed-off-by: Fred Amaral <fred@fredamaral.com.br>
📝 WalkthroughWalkthroughThis PR introduces a new "br-spi" multi-component Helm chart for deploying the BACEN SPI/DICT/Pix rail. It includes chart metadata, shared templating for four components (core, spi, brcode, dict), a detached migrations job/secret pair, default values, a JSON schema, documentation, and a CI render-values fixture. Changesbr-spi Helm chart introduction
Sequence Diagram(s)sequenceDiagram
participant ComponentTemplate as core/spi/brcode/dict template
participant ComponentTpl as _component.tpl
participant Helpers as _helpers.tpl
ComponentTemplate->>ComponentTpl: include br-spi.componentDeployment(context, component)
ComponentTpl->>Helpers: resolve names/labels/secret refs
ComponentTpl-->>ComponentTemplate: rendered manifest
sequenceDiagram
participant ArgoCD
participant MigrationsSecret as migrations Secret
participant MigrationsJob as migrations Job
participant Postgres
ArgoCD->>MigrationsSecret: apply PreSync hook (weight -2)
ArgoCD->>MigrationsJob: apply PreSync hook (weight -1)
MigrationsJob->>Postgres: wait via nc initContainer
MigrationsJob->>Postgres: run golang-migrate using POSTGRES_PASSWORD
Related Issues: None found. Related PRs: None found. Suggested labels: helm-chart, new-feature Suggested reviewers: LerianStudio/platform-team Poem
✨ Finishing Touches✨ Simplify code
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: 7
🤖 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/br-spi/Chart.yaml`:
- Around line 41-49: The Chart.yaml dependencies still reference the PostgreSQL
Bitnami chart from the legacy repository, so update the postgresql entry in the
dependencies list to use the same OCI source as valkey. Keep the existing
version and condition, but change the repository for postgresql 16.3.5 to
oci://registry-1.docker.io/bitnamicharts so both Bitnami dependencies are
sourced consistently.
In `@charts/br-spi/templates/_component.tpl`:
- Around line 142-149: The pod template in the component template does not
include checksum annotations for ConfigMap or Secret data, so changes to
<component>.configmap or <component>.secrets won’t trigger a rollout. Update the
template around the existing annotations/labels in br-spi.componentLabels to add
pod template annotations that hash the relevant ConfigMap and Secret contents,
using the component values already available in $cv/$c so Helm upgrades force a
Deployment restart when those inputs change.
- Around line 24-32: The postgres and valkey host fallback logic in
_component.tpl directly reads $ctx.Values.postgresql.enabled and
$ctx.Values.valkey.enabled, which can panic if either value is null or missing.
Update the $pgHost and $redisHost conditional checks to guard those maps before
dereferencing .enabled, following the same defensive pattern already used in
componentSecret and componentDeployment with default dict.
In `@charts/br-spi/templates/_helpers.tpl`:
- Around line 50-54: The truncation budget in br-spi.componentFullname is off by
one for the longest component name, since the base is trimmed to 57 and then a
7-character suffix can briefly exceed 63 before the final truncation. Tighten
the constant used in the $base calculation so the intermediate length stays
within the intended limit before printf and the final truncSuffix trim, keeping
the logic clear and aligned with the 63-char constraint.
- Around line 82-89: The br-spi-migrations.labels helper is using the
release-qualified fullname for app.kubernetes.io/name, which makes it
inconsistent with br-spi.componentSelectorLabels and the standard Kubernetes
label convention. Update br-spi-migrations.labels to use the chart/app name
helper (the same symbol used by br-spi.componentSelectorLabels) for
app.kubernetes.io/name, while keeping app.kubernetes.io/instance tied to
.Release.Name so the migrations resources label-match the other workloads
consistently.
In `@charts/br-spi/templates/common/NOTES.txt`:
- Around line 19-24: The NOTES template in the streaming reminder block is using
.Values.core.configmap.STREAMING_ENABLED and
.Values.spi.configmap.STREAMING_ENABLED without considering whether core or spi
are enabled, which can produce a misleading reminder for disabled components.
Update the condition in NOTES.txt to gate each STREAMING_ENABLED check behind
the corresponding .Values.core.enabled or .Values.spi.enabled flag, using the
existing configmap keys only when that component is actually deployed.
In `@charts/br-spi/values-template.yaml`:
- Line 13: The ENV_NAME setting in the spi, brcode, and dict sections is missing
the REQUIRED-to-change environment warning that the other scaffolded fields
already have. Update each ENV_NAME entry in values-template.yaml to use the same
inline comment style as POSTGRES_HOST, STREAMING_BROKERS, BACEN_SPI_ENDPOINT,
and REDIS_HOST so operators are clearly prompted to change it before production
use.
🪄 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: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 89543d2f-456d-4ca1-acb5-64cdd635f27f
⛔ Files ignored due to path filters (1)
charts/br-spi/Chart.lockis excluded by!**/*.lock
📒 Files selected for processing (40)
.github/configs/helm-render-values/br-spi.yamlcharts/br-spi/Chart.yamlcharts/br-spi/README.mdcharts/br-spi/templates/_component.tplcharts/br-spi/templates/_helpers.tplcharts/br-spi/templates/brcode/configmap.yamlcharts/br-spi/templates/brcode/deployment.yamlcharts/br-spi/templates/brcode/hpa.yamlcharts/br-spi/templates/brcode/ingress.yamlcharts/br-spi/templates/brcode/pdb.yamlcharts/br-spi/templates/brcode/secrets.yamlcharts/br-spi/templates/brcode/service.yamlcharts/br-spi/templates/common/NOTES.txtcharts/br-spi/templates/common/serviceaccount.yamlcharts/br-spi/templates/core/configmap.yamlcharts/br-spi/templates/core/deployment.yamlcharts/br-spi/templates/core/hpa.yamlcharts/br-spi/templates/core/ingress.yamlcharts/br-spi/templates/core/pdb.yamlcharts/br-spi/templates/core/secrets.yamlcharts/br-spi/templates/core/service.yamlcharts/br-spi/templates/dict/configmap.yamlcharts/br-spi/templates/dict/deployment.yamlcharts/br-spi/templates/dict/hpa.yamlcharts/br-spi/templates/dict/ingress.yamlcharts/br-spi/templates/dict/pdb.yamlcharts/br-spi/templates/dict/secrets.yamlcharts/br-spi/templates/dict/service.yamlcharts/br-spi/templates/migrations/job.yamlcharts/br-spi/templates/migrations/secrets.yamlcharts/br-spi/templates/spi/configmap.yamlcharts/br-spi/templates/spi/deployment.yamlcharts/br-spi/templates/spi/hpa.yamlcharts/br-spi/templates/spi/ingress.yamlcharts/br-spi/templates/spi/pdb.yamlcharts/br-spi/templates/spi/secrets.yamlcharts/br-spi/templates/spi/service.yamlcharts/br-spi/values-template.yamlcharts/br-spi/values.schema.jsoncharts/br-spi/values.yaml
| dependencies: | ||
| - name: postgresql | ||
| version: "16.3.5" | ||
| repository: "https://charts.bitnami.com/bitnami" | ||
| condition: postgresql.enabled | ||
| - name: valkey | ||
| version: "2.4.7" | ||
| repository: "oci://registry-1.docker.io/bitnamicharts" | ||
| condition: valkey.enabled |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🔵 Trivial | ⚡ Quick win
🧩 Analysis chain
🌐 Web query:
Is the Bitnami classic chart repository charts.bitnami.com/bitnami still available in 2026, or has PostgreSQL moved to OCI-only distribution?
💡 Result:
As of July 3, 2026, the traditional Bitnami Helm chart repository (https://charts.bitnami.com/bitnami) is considered deprecated and is not the recommended method for accessing Bitnami charts [1][2]. While it may still technically resolve in some contexts, it has been replaced by OCI-based distribution [3][2]. Bitnami completed its transition to OCI-only distribution for its Helm charts well before 2026 [4][2]. Furthermore, as of August 28, 2025, Bitnami stopped publishing new public updates for its Helm charts on Docker Hub [2]. For ongoing updates and security support for charts like PostgreSQL, users are directed to use the Bitnami Secure Images catalog, which requires a subscription [5][6][2]. For existing deployments, you should no longer rely on the charts.bitnami.com repository [2]. If you need to continue using older Bitnami charts, you must migrate your configurations to use OCI-based installation (e.g., oci://registry-1.docker.io/bitnamicharts/postgresql) [7][2] and, for image-related updates or continued access, manually override the container image registry to point to the bitnamilegacy repository or a secure alternative as required by your subscription level [8][6][9].
Citations:
- 1: https://charts.bitnami.com/ Index and Version mismatch; Out-of-sync bitnami/charts#31468
- 2: https://oneuptime.com/blog/post/2026-03-05-helmrepository-bitnami-charts-flux/view
- 3: https://blog.bitnami.com/2023/04/httpsblog.bitnami.com202304bitnami-helm-charts-now-oci.html
- 4: 🔊 Transitioning Bitnami Helm charts to OCI for enhanced security, efficiency, and compatibility bitnami/charts#30110
- 5: Clarification on Helm Chart Repository Changes bitnami/charts#35351
- 6: bitnami legacy charts bitnami/charts#36215
- 7: https://github.com/bitnami/charts/tree/main/bitnami/postgresql
- 8: Clarification on bitnami/charts after August 28th bitnami/charts#35256
- 9: charts.bitnami.com is not supported. bitnami/charts#36327
🌐 Web query:
Bitnami PostgreSQL chart 16.3.5 repository charts.bitnami.com/bitnami or oci://registry-1.docker.io/bitnamicharts: does version 16.3.5 exist and is the legacy repo still a supported source?
💡 Result:
Yes, Bitnami PostgreSQL Helm chart version 16.3.5 exists; it was released on January 3, 2025 [1]. Regarding the status of the repository sources: 1. Legacy HTTP Repository (charts.bitnami.com/bitnami): While this repository URL remains functional for backward compatibility, it has been deprecated as the primary distribution method [2][3][4]. Bitnami transitioned to OCI-based distribution as the standard method starting in November 2024 [3][5][4]. The index.yaml served at this legacy URL now points to the OCI artifacts [2][3]. 2. OCI Registry (oci://registry-1.docker.io/bitnamicharts): This is the current, supported, and recommended source for all Bitnami Helm charts [3][4][6]. Important Note on Image Availability: Following catalog changes in 2025, while the Helm charts themselves remain available in the OCI registry [7][8], many charts require updating their container image references [7][9][8]. As of late 2025, only a specific subset of charts (including PostgreSQL) are configured to work out-of-the-box with supported Bitnami Secure Images [8]. Other charts may require you to override the image repository to point to a valid source (such as the legacy image registry or a private registry) to remain functional [7][9][8]. The legacy image registry (docker.io/bitnamilegacy) is not actively maintained and should only be used for temporary migration purposes [7][9].
Citations:
- 1: https://github.com/bitnami/charts/blob/466dbcda/bitnami/postgresql/CHANGELOG.md
- 2: Chart repo problems? bitnami/charts#30609
- 3: 🔊 Transitioning Bitnami Helm charts to OCI for enhanced security, efficiency, and compatibility bitnami/charts#30110
- 4: https://community.broadcom.com/blogs/carlos-rodriguez-hernandez/2025/01/14/bitnami-helm-charts-moving-to-oci
- 5: https://blog.bitnami.com/2024/10/bitnami-helm-charts-moving-to-oci.html
- 6: https://blog.bitnami.com/2023/04/httpsblog.bitnami.com202304bitnami-helm-charts-now-oci.html
- 7: bitnami legacy charts bitnami/charts#36215
- 8: Clarification on Helm Chart Repository Changes bitnami/charts#35351
- 9: Clarification on bitnami/charts after August 28th bitnami/charts#35256
Move the PostgreSQL Bitnami dependency to OCI. postgresql 16.3.5 still exists at the legacy repo, but charts.bitnami.com/bitnami is deprecated; using oci://registry-1.docker.io/bitnamicharts for both Bitnami charts keeps the source consistent.
🤖 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/br-spi/Chart.yaml` around lines 41 - 49, The Chart.yaml dependencies
still reference the PostgreSQL Bitnami chart from the legacy repository, so
update the postgresql entry in the dependencies list to use the same OCI source
as valkey. Keep the existing version and condition, but change the repository
for postgresql 16.3.5 to oci://registry-1.docker.io/bitnamicharts so both
Bitnami dependencies are sourced consistently.
| {{- $reserved := list "POSTGRES_HOST" "REDIS_HOST" "STREAMING_ENABLED" "STREAMING_BROKERS" "STREAMING_CLOUDEVENTS_SOURCE" -}} | ||
| {{- $pgHost := $cv.configmap.POSTGRES_HOST -}} | ||
| {{- if and (not $pgHost) (ne (toString $ctx.Values.postgresql.enabled) "false") -}} | ||
| {{- $pgHost = printf "%s.%s.svc.cluster.local." (include "common.names.dependency.fullname" (dict "chartName" "postgresql" "chartValues" $ctx.Values.postgresql "context" $ctx)) (include "global.namespace" $ctx) -}} | ||
| {{- end -}} | ||
| {{- $redisHost := $cv.configmap.REDIS_HOST -}} | ||
| {{- if and (not $redisHost) (ne (toString $ctx.Values.valkey.enabled) "false") -}} | ||
| {{- $redisHost = printf "%s-primary.%s.svc.cluster.local.:6379" (include "common.names.dependency.fullname" (dict "chartName" "valkey" "chartValues" $ctx.Values.valkey "context" $ctx)) (include "global.namespace" $ctx) -}} | ||
| {{- end -}} |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
set -euo pipefail
printf '\n== files ==\n'
git ls-files charts/br-spi/templates/_component.tpl charts/br-spi/values.yaml charts/br-spi/values*.yaml | cat
printf '\n== outline _component.tpl ==\n'
ast-grep outline charts/br-spi/templates/_component.tpl --view expanded
printf '\n== relevant lines around componentConfigMap ==\n'
sed -n '1,120p' charts/br-spi/templates/_component.tpl | cat -n
printf '\n== values defaults search ==\n'
rg -n '^(postgresql|valkey):|enabled:' charts/br-spi/values.yaml charts/br-spi/values*.yaml
printf '\n== search for checksum annotations ==\n'
rg -n 'checksum|configmap|secret' charts/br-spi/templates charts/br-spi/values.yamlRepository: LerianStudio/helm
Length of output: 15430
🏁 Script executed:
set -euo pipefail
python3 - <<'PY'
from pathlib import Path
p = Path('charts/br-spi/templates/_component.tpl')
for i, line in enumerate(p.read_text().splitlines(), 1):
if 20 <= i <= 40:
print(f"{i:4d}: {line}")
PYRepository: LerianStudio/helm
Length of output: 1530
Guard postgresql and valkey before reading .enabled. The chart defaults define both maps, but a downstream override can still replace either with null or omit it entirely, and this direct dereference will panic; componentSecret and componentDeployment already use | default dict for the same lookups.
🤖 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/br-spi/templates/_component.tpl` around lines 24 - 32, The postgres
and valkey host fallback logic in _component.tpl directly reads
$ctx.Values.postgresql.enabled and $ctx.Values.valkey.enabled, which can panic
if either value is null or missing. Update the $pgHost and $redisHost
conditional checks to guard those maps before dereferencing .enabled, following
the same defensive pattern already used in componentSecret and
componentDeployment with default dict.
| template: | ||
| metadata: | ||
| {{- with $cv.podAnnotations }} | ||
| annotations: | ||
| {{- toYaml . | nindent 8 }} | ||
| {{- end }} | ||
| labels: | ||
| {{- include "br-spi.componentLabels" (dict "context" $ctx "component" $c) | nindent 8 }} |
There was a problem hiding this comment.
🩺 Stability & Availability | 🔵 Trivial | ⚡ Quick win
Consider config/secret checksum annotations to trigger rollouts on data changes.
Neither the ConfigMap nor Secret content is hashed into a pod template annotation. A helm upgrade that only changes <component>.configmap or <component>.secrets values won't roll the Deployment's pods, so the running containers keep stale env until something else (image bump, manual restart) cycles them.
♻️ Proposed fix
metadata:
+ annotations:
+ checksum/config: {{ include "br-spi.componentConfigMap" (dict "context" $ctx "component" $c) | sha256sum }}
+ checksum/secret: {{ include "br-spi.componentSecret" (dict "context" $ctx "component" $c) | sha256sum }}
{{- with $cv.podAnnotations }}
- annotations:
{{- toYaml . | nindent 8 }}
{{- end }}🤖 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/br-spi/templates/_component.tpl` around lines 142 - 149, The pod
template in the component template does not include checksum annotations for
ConfigMap or Secret data, so changes to <component>.configmap or
<component>.secrets won’t trigger a rollout. Update the template around the
existing annotations/labels in br-spi.componentLabels to add pod template
annotations that hash the relevant ConfigMap and Secret contents, using the
component values already available in $cv/$c so Helm upgrades force a Deployment
restart when those inputs change.
| {{/* Component fullname, e.g. br-spi-core */}} | ||
| {{- define "br-spi.componentFullname" -}} | ||
| {{- $base := include "br-spi.fullname" .context | trunc 57 | trimSuffix "-" -}} | ||
| {{- printf "%s-%s" $base .component | trunc 63 | trimSuffix "-" -}} | ||
| {{- end -}} |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low value
Truncation budget can still exceed 63 chars before the final trim.
$base is truncated to 57 chars, then -brcode (7 chars) is appended, yielding up to 64 chars before the final trunc 63. The last-mile trunc 63 | trimSuffix "-" masks this, so functionally it's safe, but the intermediate math is off-by-one for the longest component name (brcode). Not a functional bug given the final truncation, just worth tightening the constant for clarity.
🤖 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/br-spi/templates/_helpers.tpl` around lines 50 - 54, The truncation
budget in br-spi.componentFullname is off by one for the longest component name,
since the base is trimmed to 57 and then a 7-character suffix can briefly exceed
63 before the final truncation. Tighten the constant used in the $base
calculation so the intermediate length stays within the intended limit before
printf and the final truncSuffix trim, keeping the logic clear and aligned with
the 63-char constraint.
| {{/* Migrations labels */}} | ||
| {{- define "br-spi-migrations.labels" -}} | ||
| helm.sh/chart: {{ include "br-spi.chart" . }} | ||
| app.kubernetes.io/name: {{ include "br-spi-migrations.fullname" . }} | ||
| app.kubernetes.io/instance: {{ .Release.Name }} | ||
| app.kubernetes.io/managed-by: {{ .Release.Service }} | ||
| app.kubernetes.io/component: migrations | ||
| {{- end -}} |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win
Migrations labels deviate from standard app.kubernetes.io/name convention.
br-spi-migrations.labels sets app.kubernetes.io/name to the full release-qualified fullname (br-spi-migrations.fullname), whereas br-spi.componentSelectorLabels (Lines 63-67) correctly uses br-spi.name (the chart/app name only) for app.kubernetes.io/name and Release.Name separately for app.kubernetes.io/instance. Baking the release name into app.kubernetes.io/name breaks the recommended Kubernetes labels convention and makes cross-resource selection by app.kubernetes.io/name inconsistent between the migrations Secret/Job and the component workloads.
♻️ Suggested fix to align with standard labels
{{- define "br-spi-migrations.labels" -}}
helm.sh/chart: {{ include "br-spi.chart" . }}
-app.kubernetes.io/name: {{ include "br-spi-migrations.fullname" . }}
+app.kubernetes.io/name: {{ include "br-spi.name" . }}
app.kubernetes.io/instance: {{ .Release.Name }}
app.kubernetes.io/managed-by: {{ .Release.Service }}
app.kubernetes.io/component: migrations
{{- end -}}📝 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.
| {{/* Migrations labels */}} | |
| {{- define "br-spi-migrations.labels" -}} | |
| helm.sh/chart: {{ include "br-spi.chart" . }} | |
| app.kubernetes.io/name: {{ include "br-spi-migrations.fullname" . }} | |
| app.kubernetes.io/instance: {{ .Release.Name }} | |
| app.kubernetes.io/managed-by: {{ .Release.Service }} | |
| app.kubernetes.io/component: migrations | |
| {{- end -}} | |
| {{/* Migrations labels */}} | |
| {{- define "br-spi-migrations.labels" -}} | |
| helm.sh/chart: {{ include "br-spi.chart" . }} | |
| app.kubernetes.io/name: {{ include "br-spi.name" . }} | |
| app.kubernetes.io/instance: {{ .Release.Name }} | |
| app.kubernetes.io/managed-by: {{ .Release.Service }} | |
| app.kubernetes.io/component: migrations | |
| {{- end -}} |
🤖 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/br-spi/templates/_helpers.tpl` around lines 82 - 89, The
br-spi-migrations.labels helper is using the release-qualified fullname for
app.kubernetes.io/name, which makes it inconsistent with
br-spi.componentSelectorLabels and the standard Kubernetes label convention.
Update br-spi-migrations.labels to use the chart/app name helper (the same
symbol used by br-spi.componentSelectorLabels) for app.kubernetes.io/name, while
keeping app.kubernetes.io/instance tied to .Release.Name so the migrations
resources label-match the other workloads consistently.
| {{- if or (eq (toString .Values.core.configmap.STREAMING_ENABLED) "true") (eq (toString .Values.spi.configmap.STREAMING_ENABLED) "true") }} | ||
|
|
||
| Streaming reminder: a component with STREAMING_ENABLED=true fails closed at boot | ||
| if STREAMING_BROKERS or STREAMING_CLOUDEVENTS_SOURCE is empty. Confirm both are | ||
| set for core and spi. | ||
| {{- end }} |
There was a problem hiding this comment.
🎯 Functional Correctness | 🔵 Trivial | 💤 Low value
Streaming check reads configmap unconditionally regardless of enabled.
.Values.core.configmap.STREAMING_ENABLED and .Values.spi.configmap.STREAMING_ENABLED are read even if core/spi are disabled. Since values.yaml always defines a configmap block per component, this won't NPE, but the resulting NOTES message could be misleading if a component is disabled yet its stale configmap.STREAMING_ENABLED value is true (implying a live streaming reminder for a component that isn't actually deployed).
🤖 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/br-spi/templates/common/NOTES.txt` around lines 19 - 24, The NOTES
template in the streaming reminder block is using
.Values.core.configmap.STREAMING_ENABLED and
.Values.spi.configmap.STREAMING_ENABLED without considering whether core or spi
are enabled, which can produce a misleading reminder for disabled components.
Update the condition in NOTES.txt to gate each STREAMING_ENABLED check behind
the corresponding .Values.core.enabled or .Values.spi.enabled flag, using the
existing configmap keys only when that component is actually deployed.
| image: | ||
| tag: "" # optional — defaults to Chart.appVersion | ||
| configmap: | ||
| ENV_NAME: "development" |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟡 Minor | ⚡ Quick win
Flag ENV_NAME: "development" as REQUIRED-to-change in this production scaffold.
Every other environment-specific field here (POSTGRES_HOST, STREAMING_BROKERS, BACEN_SPI_ENDPOINT, REDIS_HOST) has an inline comment calling it out as REQUIRED or environment-dependent. ENV_NAME doesn't, even though it gates a security-relevant behavior (BACEN mTLS validation bypass under development). An operator filling in this template for staging/prod could easily leave it as-is and unknowingly ship with relaxed BACEN validation.
📝 Proposed fix
core:
configmap:
- ENV_NAME: "development"
+ ENV_NAME: "development" # REQUIRED — set to your target environment (dev bypasses BACEN mTLS validation)Apply the same comment to the spi, brcode, and dict blocks.
Also applies to: 24-24, 34-34, 41-41
🤖 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/br-spi/values-template.yaml` at line 13, The ENV_NAME setting in the
spi, brcode, and dict sections is missing the REQUIRED-to-change environment
warning that the other scaffolded fields already have. Update each ENV_NAME
entry in values-template.yaml to use the same inline comment style as
POSTGRES_HOST, STREAMING_BROKERS, BACEN_SPI_ENDPOINT, and REDIS_HOST so
operators are clearly prompted to change it before production use.
The release pipeline's prepareCmd (update-chart-version-readme --chart br-spi) requires a '### ...br spi...' section with a Chart Version matrix table in the root README.md. It was missing, so the br-spi release job failed on BOTH channels (#1607 main, #1608 develop) with 'Could not find section for chart br-spi' — the chart never published to OCI. Adds the section so future br-spi releases succeed. Verified locally: the prepareCmd binary now finds the section and updates the Chart Version cell (exit 0). README-only, so this merge itself triggers no release (paths-ignore); the first publish rides the next charts/br-spi change. Claude-Session: https://claude.ai/code/session_012fNphWnucMKd84KskVFgvz Signed-off-by: Fred Amaral <fred@fredamaral.com.br>
1 participant
What
Backfills the
develop(prerelease) channel with the br-spi-helm chart.Why
The chart landed on
mainvia #1607 (merged direct-to-main), so it published on the stable channel but was absent fromdevelop. In this repo's dual-channel semantic-release flow (develop= beta,main= stable),developshould be a superset ofmain; a chart present only onmainshows up as "deleted-on-develop" noise on the next promotion and is invisible to develop-based work.Scope
charts/br-spi/(41 files, identical to the mergedmainstate at c2fe0ac) + its render fixture.github/configs/helm-render-values/br-spi.yaml.Verification
Local gates re-run green on
mainbefore merge (strict validate: 0 violations; render-gate br-spi: ok; helm lint: 0; template: ok; br-spi values.schema.json unchanged). Cherry-pick ontodevelopis conflict-free (all paths new; no overlap with the 29 develop-ahead commits).https://claude.ai/code/session_012fNphWnucMKd84KskVFgvz