Web 471/postgress pipeline#2
Conversation
❌ Version Check Failed❌ Chart.yaml version (0.1.0) must be bumped from latest release (0.1.0) Required ActionPlease update the Tip: Use semantic versioning:
|
Review Summary by QodoAdd version check workflow and improve Helm release pipeline
WalkthroughsDescription• Add PR version check workflow to enforce semantic versioning • Improve release workflow with dependency building and index management • Align service naming with Bitnami deployment standards • Enhance Helm chart naming logic for release name handling Diagramflowchart LR
PR["Pull Request"] -->|triggers| VersionCheck["PR Version Check<br/>Workflow"]
VersionCheck -->|validates| ChartVersion["Chart.yaml<br/>Version Bump"]
ChartVersion -->|posts result| PRComment["PR Comment<br/>with Status"]
Release["Release Workflow"] -->|builds| Dependencies["Chart<br/>Dependencies"]
Dependencies -->|packages| HelmChart["Helm Chart<br/>Package"]
HelmChart -->|creates| GitRelease["GitHub Release"]
GitRelease -->|updates| RepoIndex["Helm Repository<br/>Index"]
RepoIndex -->|pushes to| GHPages["gh-pages Branch"]
File Changes1. .github/workflows/pr-version-check.yml
|
Code Review by Qodo
1. Service name mismatch
|
CI Feedback 🧐A test triggered by this PR failed. Here is an AI-generated analysis of the failure:
|
| kind: Service | ||
| metadata: | ||
| name: {{ include "postgresql.primary.svcName" . }} | ||
| name: {{ .Release.Name }}-postgresql |
There was a problem hiding this comment.
1. Service name mismatch 🐞 Bug ✓ Correctness
The primary Service is renamed to {{ .Release.Name }}-postgresql, but NOTES.txt (and the
existing postgresql.primary.svcName helper) still point users to a different service name derived
from postgresql.fullname. This will cause the documented DNS/psql/port-forward commands to fail
and also bypass nameOverride/fullnameOverride for the Service name.
Agent Prompt
### Issue description
The primary Service name is hard-coded to `{{ .Release.Name }}-postgresql`, but the chart’s helper (`postgresql.primary.svcName`) and `NOTES.txt` still reference a different name derived from `postgresql.fullname`. This breaks the documented connection instructions and makes naming overrides inconsistent.
### Issue Context
- `templates/service.yaml` uses a hard-coded name.
- `templates/NOTES.txt` uses `postgresql.primary.svcName`.
- `postgresql.primary.svcName` resolves to `postgresql.fullname`.
### Fix Focus Areas
- templates/service.yaml[1-8]
- templates/NOTES.txt[5-8]
- templates/_helpers.tpl[150-159]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
| {{- $name := default .Chart.Name .Values.nameOverride }} | ||
| {{- if contains $name .Release.Name }} | ||
| {{- .Release.Name | trunc 63 | trimSuffix "-" }} | ||
| {{- else if contains .Release.Name $name }} | ||
| {{- $name | trunc 63 | trimSuffix "-" }} | ||
| {{- else }} | ||
| {{- printf "%s-%s" .Release.Name $name | trunc 63 | trimSuffix "-" }} |
There was a problem hiding this comment.
2. Fullname collision risk 🐞 Bug ⛯ Reliability
postgresql.fullname can now return the bare chart name when the release name is a substring of the chart name, which can cause multiple releases in the same namespace to generate identical resource names. This can lead to install/upgrade failures and cross-release resource collisions for StatefulSet/Secret/NetworkPolicy names that use postgresql.fullname.
Agent Prompt
### Issue description
`postgresql.fullname` may return the chart name without the release name when the release name is a substring of the chart name. Since many resources use `postgresql.fullname` for `metadata.name`, this can create cross-release naming collisions and break installs/upgrades.
### Issue Context
The added branch:
- triggers when `contains .Release.Name $name` (i.e., `$name` contains the release name)
- returns `$name` only
### Fix Focus Areas
- templates/_helpers.tpl[12-23]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
No description provided.