Web 316/postgress pipeline

[itaydj]

No description provided.

[github-actions]

✅ Version Check Passed

✅ Version bumped: 0.1.0 → 1.0.0 (major)

This PR can be merged.

[qodo-code-review]

Review Summary by Qodo

Add version check workflow and improve release pipeline

✨ Enhancement 🧪 Tests

Walkthroughs

Description

• 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
• Add release summary to GitHub Actions workflow

Diagram

flowchart LR
  PR["Pull Request"] -->|triggers| VersionCheck["PR Version Check<br/>Workflow"]
  VersionCheck -->|validates| ChartVersion["Chart.yaml<br/>Version Bump"]
  ChartVersion -->|posts| Comment["PR Comment<br/>with Status"]
  Release["Release Workflow"] -->|builds| Dependencies["Chart<br/>Dependencies"]
  Dependencies -->|packages| Helm["Helm Chart<br/>Package"]
  Helm -->|creates| GitRelease["GitHub Release"]
  GitRelease -->|updates| Index["Helm Repository<br/>Index"]
  Index -->|publishes| GHPages["gh-pages Branch"]
  Service["Service Template"] -->|aligns| Naming["Service Name<br/>with Bitnami"]

Loading

File Changes

1. .github/workflows/pr-version-check.yml 🧪 Tests +148/-0

New PR version validation workflow

• New workflow file that validates Chart.yaml version bumps on pull requests
• Compares PR version against latest release tag using semantic versioning
• Posts automated comments on PR with version check results
• Fails the check if version is not bumped or not greater than latest release

.github/workflows/pr-version-check.yml

---

2. .github/workflows/release.yml ✨ Enhancement +49/-7

Enhance release workflow with dependencies and summary

• Replace helm lint with helm dependency build step for building chart dependencies
• Add Chart.lock file detection before building dependencies
• Add directory listing output after packaging chart
• Improve Helm repository index generation with conditional merge logic
• Add cleanup steps for temporary package directories
• Add release summary section to GitHub Actions workflow output

.github/workflows/release.yml

---

3. templates/_helpers.tpl ✨ Enhancement +2/-0

Improve fullname template logic

• Add additional condition to handle case where release name contains chart name
• Improve fullname template logic for better name generation flexibility

templates/_helpers.tpl

---

View more (1)

4. templates/service.yaml ⚙️ Configuration changes +1/-1

Align service name with Bitnami deployment

• Change service name from helper function to direct release name with postgresql suffix
• Align service naming convention with Bitnami PostgreSQL deployment standards

templates/service.yaml

---

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (4) 📘 Rule violations (0) 📎 Requirement gaps (0)

1. Fullname may collide ☑ 🐞 Bug ✓ Correctness

Description

The updated fullname helper can return just the chart name when the chart name contains the release
name, dropping .Release.Name from resource names. This can cause resource-name collisions (and
failed installs or cross-release resource overlap) when installing multiple releases whose names are
substrings of the chart name in the same namespace.

Code

templates/_helpers.tpl[R19-20]

+{{- else if contains .Release.Name $name }}
+{{- $name | trunc 63 | trimSuffix "-" }}

Evidence

The new branch returns $name (chart name / nameOverride) when it contains the release name, which
makes names independent of the release for that case. Since core objects (StatefulSet, Secret,
NetworkPolicy, etc.) are named using postgresql.fullname, any collision in fullname becomes a
collision for those objects. With chart name "webrix-postgres", common release names like "postgres"
or "webrix" are substrings of the chart name, so two such releases in the same namespace would both
attempt to create resources named "webrix-postgres".

templates/_helpers.tpl[12-23]
Chart.yaml[1-6]
templates/statefulset.yaml[1-16]
templates/secret.yaml[1-7]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`postgresql.fullname` can drop `.Release.Name` when the chart name contains the release name. This can make multiple releases in the same namespace generate identical resource names.
### Issue Context
Many core resources use `include "postgresql.fullname" .` for their `metadata.name`, so any fullname collision breaks installs/upgrades.
### Fix Focus Areas
- templates/_helpers.tpl[12-23]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Service/helper mismatch ☑ 🐞 Bug ✓ Correctness

Description

The primary Service was renamed to {{ .Release.Name }}-postgresql, but the chart helper
postgresql.primary.svcName (used by NOTES) still resolves to postgresql.fullname. This makes
NOTES/connection instructions point to a Service name that will not exist and also introduces a
breaking service DNS change on upgrade.

Code

templates/service.yaml[5]

+  name: {{ .Release.Name }}-postgresql

Evidence

The primary Service now uses a hardcoded naming scheme based on .Release.Name, while the canonical
helper still returns postgresql.fullname and NOTES uses that helper to generate DNS names and
kubectl commands. This inconsistency guarantees incorrect instructions and will break users/clients
relying on the previous Service DNS name derived from fullname.

templates/service.yaml[1-9]
templates/_helpers.tpl[154-159]
templates/NOTES.txt[5-8]
templates/NOTES.txt[25-32]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Primary Service `metadata.name` no longer matches the chart's `postgresql.primary.svcName` helper, and NOTES relies on that helper.
### Issue Context
This causes NOTES/commands to reference a Service that doesn't exist and changes service DNS name across upgrades.
### Fix Focus Areas
- templates/service.yaml[1-8]
- templates/_helpers.tpl[154-159]
- templates/NOTES.txt[5-45]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. Version check fails open 🐞 Bug ⛯ Reliability

Description

The PR version-check workflow treats an empty latest_tag as "no releases" and exits success, but
latest_tag can also be empty when the GitHub API call fails (errors are suppressed). This makes
the check fail-open during transient/auth/rate-limit issues.

Code

.github/workflows/pr-version-check.yml[R42-49]

+          latest_tag=$(gh api repos/${{ github.repository }}/tags --jq '.[0].name' 2>/dev/null || echo "")
+
+          if [ -z "$latest_tag" ]; then
+            echo "ℹ️  No existing releases found"
+            echo "✅ This will be the first release with version: $pr_version"
+            echo "status=success" >> $GITHUB_OUTPUT
+            echo "message=✅ First release - version $pr_version will be used" >> $GITHUB_OUTPUT
+            exit 0

Evidence

The workflow explicitly suppresses gh api errors (stderr redirected + || echo "") and then
interprets empty output as "No existing releases found" and returns success. That makes API failures
indistinguishable from a true "first release" case.

.github/workflows/pr-version-check.yml[41-50]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The version check cannot distinguish "no tags" from "could not fetch tags" and currently treats both as success.
### Issue Context
This can allow merges without a verified version bump when GitHub API calls fail.
### Fix Focus Areas
- .github/workflows/pr-version-check.yml[41-50]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

4. Release missing validation 🐞 Bug ⛯ Reliability

Description

The release workflow no longer performs any Helm validation (e.g., helm lint/helm template)
before packaging and publishing a release and updating index.yaml. This increases the risk of
publishing a broken chart.

Code

.github/workflows/release.yml[R60-72]

+      - name: Build chart dependencies
       if: steps.check_release.outputs.exists == 'false'
-        run: helm lint .
+        run: |
+          echo "🔨 Building chart dependencies..."
+          if [ -f "Chart.lock" ]; then
+            helm dependency build
+            echo "✅ Dependencies built"
+          else
+            echo "ℹ️  No dependencies to build"
+          fi

     - name: Package Helm chart
       if: steps.check_release.outputs.exists == 'false'

Evidence

The workflow proceeds from dependency build directly to helm package and then creates a GitHub
Release, without any lint/template validation step in between.

.github/workflows/release.yml[60-78]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Chart releases are published without any Helm validation, increasing the chance of shipping a broken chart.
### Issue Context
`helm package` does not provide the same validation coverage as `helm lint`/render checks.
### Fix Focus Areas
- .github/workflows/release.yml[60-78]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

ⓘ The new review experience is currently in Beta. Learn more