[OpinionatedHeron]

Description of the change

Updating helper in _helpers.tpl to return the admin key when username is postgres and the user key otherwise, then use it in deployment.yaml.

Which issue(s) does this PR fix or relate to

• RHDHBUGS-3689

Checklist

• For each Chart updated, version bumped in the corresponding Chart.yaml according to Semantic Versioning.
• For each Chart updated, variables are documented in the values.yaml and added to the corresponding README.md. The pre-commit utility can be used to generate the necessary content. Run pre-commit run --all-files to run the hooks and then push any resulting changes. The pre-commit Workflow will enforce this and warn you if needed.
• JSON Schema template updated and re-generated the raw schema via the pre-commit hook.
• Tests pass using the Chart Testing tool and the ct lint command.
• If you updated the orchestrator-infra chart, make sure the versions of the Knative CRDs are aligned with the versions of the CRDs installed by the OpenShift Serverless operators declared in the values.yaml file. See Installing Knative Eventing and Knative Serving CRDs for more details.

[rhdh-qodo-merge]

PR Summary by Qodo

Fix PostgreSQL password key selection for custom usernames

🐞 Bug fix 🕐 10-20 Minutes

AI Description

• Select the user password key for custom PostgreSQL usernames while retaining the admin key for
 postgres.
• Bump the RHDH chart to 3.4.8 and update its documented install version.

Diagram

graph TD
  Values["PostgreSQL auth"] --> Choice{"Username postgres?"} -->|yes| Admin["Admin password key"] --> Pod["Pod secret reference"] --> Secret["PostgreSQL Secret"]
  Choice -->|no| User["User password key"] --> Pod

Loading

High-Level Assessment

The shared helper is appropriate: it keeps the username-dependent choice beside the existing PostgreSQL key helper and preserves default behavior. An inline conditional in the pod template would work but would separate this decision from the other secret-key logic.

Files changed (4) +16 / -4

Bug fix (2) +13 / -1

_backstage-pod-template.tplUse username-aware key for the pod password +1/-1

Use username-aware key for the pod password

• Changes the built-in PostgreSQL POSTGRES_PASSWORD secret reference to use the new password-key helper instead of always using the admin key.

charts/rhdh/templates/_backstage-pod-template.tpl

_helpers.tplSelect PostgreSQL password key by username +12/-0

Select PostgreSQL password key by username

• Adds a helper that returns the admin password key for the default 'postgres' username and the configured user password key for a custom username. The user key defaults to 'password'.

charts/rhdh/templates/_helpers.tpl

Documentation (1) +2 / -2

README.mdUpdate documented chart version +2/-2

Update documented chart version

• Changes the version badge and Helm installation example to 3.4.8.

charts/rhdh/README.md

Other (1) +1 / -1

Chart.yamlBump RHDH chart version to 3.4.8 +1/-1

Bump RHDH chart version to 3.4.8

• Increments the chart patch version for the PostgreSQL password-key fix; the application version remains 2.1.0.

charts/rhdh/Chart.yaml

[rhdh-qodo-merge]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Custom users can read the wrong password 🐞 Bug ≡ Correctness

Description

rhdh.postgresql.passwordKey reads only the local userPasswordKey for a non-postgres username,
ignoring the global key override. When a local existing Secret is used with a different
global.postgresql.auth.secretKeys.userPasswordKey, the application references a different Secret
key from the one selected for the database user, so its pod can fail to start or authenticate.

Code

charts/rhdh/templates/_helpers.tpl[183]

+        {{- (((((.Values).postgresql).auth).secretKeys).userPasswordKey) | default "password" -}}

Relevance

●●● Strong

Clear PostgreSQL Secret-key precedence bug; similar helper and database-auth correctness fixes were
accepted.

PR-#500
PR-#173

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The changed helper chooses only the local user key, and the pod uses its result for
POSTGRES_PASSWORD. The repository’s vendored Backstage chart shows global-before-local precedence
for the PostgreSQL user-password key when an existing Secret is configured; the RHDH chart declares
a Bitnami PostgreSQL dependency.

charts/rhdh/templates/_helpers.tpl[179-184]
charts/rhdh/templates/_backstage-pod-template.tpl[331-337]
charts/rhdh/templates/_helpers.tpl[155-163]
charts/backstage/vendor/backstage/charts/backstage/templates/_helpers.tpl[54-70]
charts/rhdh/Chart.yaml[29-40]

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 new non-postgres password-key branch ignores the global PostgreSQL user-password key override, which can make the application read a different key from the database.

## Fix Focus Areas
- charts/rhdh/templates/_helpers.tpl[179-184]

## Recommended Fix
Select `global.postgresql.auth.secretKeys.userPasswordKey` before the local key, retaining `password` as the fallback. Add a rendering test with a non-postgres username, a local existing Secret, and distinct global and local user-password keys.

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

Dismiss ↗ | View ↗

---

Context sources

⚠️ Tickets: not configured — ticket URL found in PR but could not be fetched — check ticket provider credentials

✅ Cross-repo context — repo relationships

  Explored: repo: redhat-developer/rhdh (sha: 873ac8e4) — View relationship

Review mode: Auto: ⚖️ Balanced: Localized Helm credential-key logic changes deployment behavior and secret compatibility.

Tip of the day

💡 Did you know, you can turn these tips off under Display > Comment parts

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[rhdh-qodo-merge]

Important

The /generate_labels command by Qodo was deprecated on the 1st of October 2026 and is no longer available. We recommend switching to the latest Qodo review capabilities. Learn more

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud