test(8.9): honor RDBMS_POSTGRESQL_USERNAME for the role in postgresql-cluster fixture#6310
Open
eamonnmoloney wants to merge 1 commit into
Open
test(8.9): honor RDBMS_POSTGRESQL_USERNAME for the role in postgresql-cluster fixture#6310eamonnmoloney wants to merge 1 commit into
eamonnmoloney wants to merge 1 commit into
Conversation
…-cluster fixture Backport of the 8.10 fix (#6293). The 8.9 postgresql-cluster CNPG fixture hardcoded the managed login role to `app`, while the connection Secret, the psql-create-db job (--username=$RDBMS_POSTGRESQL_USERNAME) and rdbms.yaml (username: ${RDBMS_POSTGRESQL_USERNAME}) all use the variable. They only agree when the var is literally `app`, so a manual deploy-camunda run with any other value failed with 'password authentication failed for user ...'. Derive the managed role name from $RDBMS_POSTGRESQL_USERNAME. The role is a superuser, so it can access the default `app` database regardless of name. When the var is `app` this renders byte-identical to before, so CI is unchanged. (8.9 creates databases via the psql-create-db job rather than postInitSQL, so unlike 8.10 there is no CREATE DATABASE owner clause to update.) Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
eamonnmoloney
force-pushed
the
fix-pg-fixture-username-89
branch
from
6c652c5 to
d60439d
Compare
eamonnmoloney
requested review from
Copilot and
hisImminence
and removed request for
a team
Contributor
There was a problem hiding this comment.
Pull request overview
Backports the 8.10 fix for postgresql-cluster CNPG test fixtures to the 8.9 chart so RDBMS scenarios remain self-consistent when RDBMS_POSTGRESQL_USERNAME is not app, preventing JDBC authentication failures during manual deploy-camunda runs.
Changes:
- Update the CNPG managed role name in the 8.9
postgresql-clusterfixture to derive from$RDBMS_POSTGRESQL_USERNAMEinstead of hardcodingapp. - Add inline rationale explaining why the role must track the JDBC username used by the chart and DB-creation job.
Comment on lines
+22
to
+23
| # "password authentication failed for user ...". In CI the var is `app`, so | ||
| # this renders identically. |
| managed: | ||
| roles: | ||
| - name: app | ||
| - name: $RDBMS_POSTGRESQL_USERNAME |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Which problem does the PR fix?
Backport of #6293 to the 8.9 chart. A manual
deploy-camundarun of an 8.9 RDBMS scenario fails withpassword authentication failed for user "..."unlessRDBMS_POSTGRESQL_USERNAMEhappens to be exactlyapp.What's in this PR?
The 8.9
postgresql-clusterCNPG fixture hardcoded the managed login role toapp, while the connectionSecret, thepsql-create-dbjob (--username=$RDBMS_POSTGRESQL_USERNAME), andrdbms.yaml(username: ${RDBMS_POSTGRESQL_USERNAME}) all use the variable. They only agree when the variable is literallyapp.This derives the managed role name from
$RDBMS_POSTGRESQL_USERNAME. The role is a superuser, so it accesses the defaultappdatabase regardless of name. When the variable isappthe fixture renders byte-identical to before, so CI is unchanged.8.9 differs from 8.10: it creates databases via the
psql-create-dbjob (notpostInitSQL), so there's noCREATE DATABASE ... OWNERclause to update — only the managed role name.Validation:
envsubstrender with=app(identical to before) and=camunda(role consistentlycamunda);go test ./matrix/...passes. Not GKE-validated for non-appvalues (no standing local 8.9 RDBMS deploy), but mirrors the GKE-validated 8.10 fix (#6293) and is a no-op when the var isappas CI uses.Checklist
Please make sure to follow our Contributing Guide.
Before opening the PR:
make go.update-golden-only.After opening the PR: