Make changes to support tilt.dev local development #264
Conversation
WalkthroughSecret values/formats updated across apps; startupProbes added to multiple statefulsets; Traefik local values adjusted; new init Jobs and RBAC ServiceAccounts/RoleBindings added to orchestrate DB and RabbitMQ provisioning; legacy init scripts removed; RabbitMQ config and values extended. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
participant Helm as Helm renderer
participant KubeAPI as Kubernetes API
participant Config as ConfigMap/Secret (faf-apps)
participant InitCnt as Job initContainer (load-config)
participant MainJob as Job main container (sync)
participant DB as Database Pod
Helm->>KubeAPI: Apply Job manifest per entry (PostSync hook)
KubeAPI->>InitCnt: Start initContainer
InitCnt->>Config: kubectl get ConfigMap/Secret (faf-apps)
Config-->>InitCnt: return env keys -> write /config/env
InitCnt-->>KubeAPI: initContainer completes
KubeAPI->>MainJob: Start main job container
MainJob->>MainJob: source /config/env, export credentials
MainJob->>DB: connect -> check/create user
MainJob->>DB: connect -> check/create database
MainJob->>DB: grant privileges
MainJob-->>KubeAPI: Exit success -> Job completes (HookSucceeded)
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: CHILL Plan: Pro 📒 Files selected for processing (1)
🔇 Additional comments (1)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 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: 4
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (11)
apps/faf-api/templates/local-secret.yaml(1 hunks)apps/faf-icebreaker/templates/local-secret.yaml(1 hunks)apps/faf-lobby-server/templates/local-secret.yaml(0 hunks)apps/ory-hydra/templates/local-secret.yaml(1 hunks)apps/rabbitmq/templates/statefulset.yaml(1 hunks)config/local.yaml(0 hunks)infra/mariadb/templates/statefulset.yaml(1 hunks)infra/mongodb/templates/statefulset.yaml(1 hunks)infra/postgres/templates/statefulset.yaml(2 hunks)scripts/init-mariadb.sh(1 hunks)scripts/init-rabbitmq.sh(1 hunks)
💤 Files with no reviewable changes (2)
- config/local.yaml
- apps/faf-lobby-server/templates/local-secret.yaml
🧰 Additional context used
🧬 Code graph analysis (1)
scripts/init-mariadb.sh (1)
scripts/k8s-helpers.sh (3)
check_resource_exists_or_fail(40-50)get_secret_value(61-63)get_config_value(57-59)
🪛 Gitleaks (8.30.0)
apps/faf-api/templates/local-secret.yaml
[high] 21-47: Identified a Private Key, which may compromise cryptographic security and sensitive data encryption.
(private-key)
apps/faf-icebreaker/templates/local-secret.yaml
[high] 17-44: Identified a Private Key, which may compromise cryptographic security and sensitive data encryption.
(private-key)
🔇 Additional comments (8)
scripts/init-rabbitmq.sh (1)
55-55: Clarify the vhost name change from/faf-coreto//faf-core.The vhost identifier was changed to use a leading double slash, which is unusual. Standard RabbitMQ vhost naming uses a single leading slash (e.g.,
/faf-core). Verify whether this change is intentional or a typo, as it may cause connection failures for services expecting the original vhost path.Is this vhost change intentional? If not, revert to the standard single-slash format:
-VHOST_FAF_CORE="//faf-core" +VHOST_FAF_CORE="/faf-core"apps/rabbitmq/templates/statefulset.yaml (1)
33-38: Startup probe configuration looks good.The
rabbitmq-diagnostics pingcommand is compatible with the image version (3.13.7), and the probe timing is appropriate. This will ensure the pod is ready before receiving traffic.infra/postgres/templates/statefulset.yaml (1)
47-50: Verify the PostgreSQL user in the startup probe.The
pg_isreadycommand uses-Uroot, but the default PostgreSQL user is typicallypostgres. This mismatch may cause the startup probe to fail. Verify whetherrootis the correct user or if it should bepostgres.If
postgresis the correct user, apply this diff:startupProbe: exec: - command: ["pg_isready", "-Uroot", "-h127.0.0.1"] + command: ["pg_isready", "-Upostgres", "-h127.0.0.1"] periodSeconds: 5apps/faf-icebreaker/templates/local-secret.yaml (1)
16-54: Verify that embedded cryptographic keys are local-development only.The JWT private and public keys are committed directly in the template. This is acceptable for local development (per the PR's tilt.dev context), but they must never be used in production. Confirm that:
- These keys are exclusively for local development environments
- Production deployments use
infisical-secret(as suggested by the conditional on line 1)- If these keys are exposed, they should be considered compromised and rotated immediately
Additionally, consider adding a comment in the file documenting that these are local-dev placeholders:
{{- if not (index .Values "infisical-secret" "enabled") }} +# Local development only - do not use in production apiVersion: v1apps/ory-hydra/templates/local-secret.yaml (1)
12-12: Local development secret value looks appropriate.The placeholder value has been updated to increase entropy. This is acceptable for local development environments.
infra/mariadb/templates/statefulset.yaml (1)
29-34: Startup probe configuration is sound.The
mariadb-admin pingcommand is the standard approach for MariaDB health checks, and the timing parameters are appropriate for a database startup scenario.apps/faf-api/templates/local-secret.yaml (1)
19-47: Verify that embedded RSA cryptographic keys are local-development only.The RSA private and public keys are committed directly in the template. This is acceptable for local development (per the PR's tilt.dev context), but they must never be used in production. Confirm that:
- These keys are exclusively for local development environments
- Production deployments use
infisical-secret(as suggested by the conditional on line 1)- If these keys are exposed, they should be considered compromised and rotated immediately
Additionally, consider adding a comment in the file documenting that these are local-dev placeholders:
{{- if not (index .Values "infisical-secret" "enabled") }} +# Local development only - do not use in production apiVersion: v1scripts/init-mariadb.sh (1)
44-44: Verify the database name for faf-icebreaker.Line 44 uses
DB_USERNAMEas both the username and database name parameter. This may be a copy-paste error. Confirm whether the database name should be distinct (e.g., a different config key likeDB_DATABASEorDB_NAME).
| startupProbe: | ||
| exec: | ||
| command: ["mongo", "--eval", "db.adminCommand('ping')"] | ||
| initialDelaySeconds: 10 | ||
| timeoutSeconds: 15 | ||
| periodSeconds: 5 |
There was a problem hiding this comment.
Incompatible MongoDB startup probe command for image version 8.2.2.
The mongo CLI tool was deprecated and removed in MongoDB 8.0. The image mongo:8.2.2 requires mongosh instead. The current command will fail, preventing the pod from starting.
Apply this diff to fix the startup probe:
startupProbe:
exec:
- command: ["mongo", "--eval", "db.adminCommand('ping')"]
+ command: ["mongosh", "--eval", "db.adminCommand('ping')"]
initialDelaySeconds: 10
timeoutSeconds: 15
periodSeconds: 5📝 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.
| startupProbe: | |
| exec: | |
| command: ["mongo", "--eval", "db.adminCommand('ping')"] | |
| initialDelaySeconds: 10 | |
| timeoutSeconds: 15 | |
| periodSeconds: 5 | |
| startupProbe: | |
| exec: | |
| command: ["mongosh", "--eval", "db.adminCommand('ping')"] | |
| initialDelaySeconds: 10 | |
| timeoutSeconds: 15 | |
| periodSeconds: 5 |
🤖 Prompt for AI Agents
In infra/mongodb/templates/statefulset.yaml around lines 31 to 36 the
startupProbe uses the removed "mongo" CLI which fails on image mongo:8.2.2;
update the probe to call "mongosh" instead and keep the same eval string (e.g.
replace ["mongo", "--eval", "db.adminCommand('ping')"] with ["mongosh",
"--eval", "db.adminCommand('ping')"]) so the probe uses the supported shell;
ensure the image actually includes mongosh and adjust timeout/periods only if
needed for the new binary startup time.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
infra/mariadb/templates/init-database-with-user.yaml (1)
97-107: Consider: Addset -eto the main container script for consistency.The init container now has
set -e(line 62), but the main container script (lines 97-107) does not. If a mariadb command fails (e.g., CREATE DATABASE fails), the script will continue and attempt to create the user anyway, potentially leaving the database in an incomplete state. This is a minor concern for idempotent CREATE IF NOT EXISTS operations, but addingset -ehere would improve robustness and fail-fast behavior.If you want to ensure the script fails on any error:
args: - | set -a . /config/env set +a + set -e mariadb -v --host=mariadb --user=root --password="${MARIADB_ROOT_PASSWORD}" -e "CREATE DATABASE IF NOT EXISTS \`${SYNC_DATABASE}\`;" 2>&1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
infra/mariadb/templates/init-database-with-user.yaml(2 hunks)
🔇 Additional comments (2)
infra/mariadb/templates/init-database-with-user.yaml (2)
62-62: Good:set -eensures init container fails on first error.Adding
set -eat the start of the init container script ensures the job fails fast if configuration loading fails (e.g., missing configmap/secret). This is a solid improvement for robustness.
101-103: The-vflag is valid and supported in the mariadb CLI.According to official MariaDB documentation,
-v/--verboseis a supported flag for the mariadb command-line client. It is repeatable (e.g.,-vvv) to increase verbosity. The single-vusage in lines 101-103 is correct and appropriate for improving visibility during command execution.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (3)
infra/mariadb/templates/init-database-with-user.yaml (1)
1-9: Remove profanity from comments.The comment block uses language that is unprofessional for production code. Replace with neutral, descriptive text explaining the three-step pattern (ServiceAccount, RBAC RoleBinding, Job iteration).
Suggested replacement:
# ========================================= # Database and User Initialization # ========================================= # # 1. Uses the init-apps ServiceAccount # 2. RoleBinding permits it to read ConfigMaps and Secrets in faf-apps namespace # 3. Iterates over databasesAndUsers list and creates a Job for each database # a) initContainer: Load the ConfigMap and Secret into environment variables. # Cross-namespace access via kubectl requires explicit RBAC binding. # b) main container: Load env from file and create the database and userinfra/postgres/templates/statefulset.yaml (1)
36-36: Minor: Inconsistent template syntax for value access.Line 36 uses
$.Values.image.repositorywhile line 20 usesindex .Values "upgrade-image" "repository". Both are valid, but prefer consistent syntax within the same template. Use dot notation throughout if all values are top-level or nested.infra/postgres/templates/init-database-with-user.yaml (1)
1-9: Remove profanity from comments.The comment block uses language that is unprofessional for production code. Replace with neutral, descriptive text explaining the three-step pattern, similar to the mariadb template.
Suggested replacement:
# ========================================= # Database and User Initialization # ========================================= # # 1. Uses the init-apps ServiceAccount # 2. RoleBinding permits it to read ConfigMaps and Secrets in faf-apps namespace # 3. Iterates over databasesAndUsers list and creates a Job for each database # a) initContainer: Load the ConfigMap and Secret into environment variables. # Cross-namespace access via kubectl requires explicit RBAC binding. # b) main container: Load env from file and create the database and user
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (7)
infra/clusterroles/templates/role-binding.yaml(1 hunks)infra/clusterroles/templates/service-account.yaml(1 hunks)infra/mariadb/templates/init-database-with-user.yaml(2 hunks)infra/postgres/templates/init-database-with-user.yaml(1 hunks)infra/postgres/templates/statefulset.yaml(2 hunks)infra/postgres/values.yaml(1 hunks)scripts/init-postgres.sh(0 hunks)
💤 Files with no reviewable changes (1)
- scripts/init-postgres.sh
🧰 Additional context used
🪛 YAMLlint (1.37.1)
infra/postgres/templates/statefulset.yaml
[error] 20-20: syntax error: expected , but found ''
(syntax)
infra/postgres/templates/init-database-with-user.yaml
[error] 11-11: syntax error: expected the node content, but found '-'
(syntax)
🔇 Additional comments (11)
infra/postgres/values.yaml (1)
1-24: LGTM!The configuration structure is correct and properly supports templated image references and database initialization. The
databasesAndUserslist entries align with the new init Job template expectations.infra/clusterroles/templates/service-account.yaml (1)
1-4: LGTM!The ServiceAccount is correctly defined and will serve as the identity for init-apps workflows.
infra/clusterroles/templates/role-binding.yaml (1)
1-13: Verify theread-cm-secretsClusterRole exists.The RoleBinding correctly binds the init-apps ServiceAccount across namespaces. Ensure the referenced
read-cm-secretsClusterRole is defined elsewhere in the cluster or in this PR.infra/mariadb/templates/init-database-with-user.yaml (1)
39-39: Good: Enhanced error handling and verbosity.The addition of
set -ein the initContainer (line 39) and-vflags to mariadb commands (lines 78-80) improve observability and fail-fast semantics during initialization, which is valuable for debugging tilt.dev local development.Also applies to: 78-80
infra/postgres/templates/statefulset.yaml (3)
20-20: YAMLlint false positive on Helm template syntax.The reported syntax error is a false positive. The Helm
{{ index ... }}notation is valid for nested value access. YAMLlint does not properly parse Helm templating directives; this file will validate correctly when processed by Helm.
25-29: Verify thepostgressecret with keyPOSTGRES_PASSWORDexists.The shift to sourcing
POSTGRES_PASSWORDfrom a secret (instead of a ConfigMap or inline value) is more secure. Ensure the secretpostgreswith keyPOSTGRES_PASSWORDis created before the StatefulSet is deployed, or is managed by a secret operator (e.g., Infisical).
47-50: Good: startup probe improves readiness detection.The
startupProbewithpg_isreadyand a 5-second period is appropriate for PostgreSQL. This ensures the StatefulSet does not route traffic before the database is ready, which is beneficial for local development with tilt.infra/postgres/templates/init-database-with-user.yaml (4)
11-11: YAMLlint false positive on Helm template syntax.The reported syntax error is a false positive. The Helm
{{- $wave := 1 }}syntax is valid for variable initialization with whitespace stripping. YAMLlint does not properly parse Helm templating; this file will validate correctly when processed by Helm.
29-29: LGTM: Proper RBAC usage and robust shell scripting.The ServiceAccount reference, error handling (
set -e), and environment variable export pattern (set -a/set +a) are correct. The idempotent database/user creation with existence checks (lines 80–95) is safe and prevents re-creation errors.Also applies to: 39-39, 74-76
43-60: Verify image availability and secret existence.Ensure that:
- The
alpine/kubectlimage (line 35) is available in your registry and supports thekubectl getoperations for ConfigMaps and Secrets.- The
postgressecret with keyPOSTGRES_PASSWORD(referenced at line 78) exists in the cluster before the Job runs.- The referenced ConfigMaps and Secrets (via
{{ .configMapRef }}and{{ .secretRef }}) are created in the faf-apps namespace before the Job is applied.The cross-namespace access pattern in the initContainer (lines 43–60) will fail silently if the RBAC RoleBinding is misconfigured or if the resources do not exist.
Also applies to: 80-95
80-80: Good: SQL injection protection via identifier quoting.The use of double-quoted identifiers in psql commands (e.g.,
CREATE USER \"${SYNC_USERNAME}\") prevents SQL injection attacks when variable values contain special characters. This is a security best practice.Also applies to: 87-87, 90-90, 94-94
There was a problem hiding this comment.
Actionable comments posted: 2
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (8)
apps/rabbitmq/templates/config.yaml(1 hunks)apps/rabbitmq/templates/init-rabbitmq-with-user.yaml(1 hunks)apps/rabbitmq/templates/statefulset.yaml(1 hunks)apps/rabbitmq/values.yaml(1 hunks)infra/clusterroles/templates/role-binding.yaml(1 hunks)infra/clusterroles/templates/service-account.yaml(1 hunks)infra/mariadb/templates/init-database-with-user.yaml(2 hunks)scripts/init-rabbitmq.sh(0 hunks)
💤 Files with no reviewable changes (1)
- scripts/init-rabbitmq.sh
✅ Files skipped from review due to trivial changes (1)
- apps/rabbitmq/templates/config.yaml
🚧 Files skipped from review as they are similar to previous changes (2)
- apps/rabbitmq/templates/statefulset.yaml
- infra/clusterroles/templates/service-account.yaml
🧰 Additional context used
🪛 YAMLlint (1.37.1)
apps/rabbitmq/templates/init-rabbitmq-with-user.yaml
[error] 11-11: syntax error: expected the node content, but found '-'
(syntax)
🔇 Additional comments (8)
infra/mariadb/templates/init-database-with-user.yaml (2)
39-39: Good addition for fail-fast error handling.Adding
set -eensures the initContainer fails immediately if anykubectlcommand fails, preventing invalid configuration from being written. This improves error visibility and prevents cascading failures in the main container.
78-80: LGTM on removing stderr redirection.Removing
2>&1allows stderr and stdout to flow naturally to their respective streams. Kubernetes will capture both streams in the container logs, and this change doesn't affect functionality.infra/clusterroles/templates/role-binding.yaml (1)
1-29: RBAC dependencies are correctly defined and referenced.The ClusterRole
read-cm-secretsis defined ininfra/clusterroles/templates/clusterrole-read-cm-secrets.yamlwith appropriate rules for configmaps and secrets. The ServiceAccountinit-appsexists in both thefaf-infraandfaf-appsnamespaces ininfra/clusterroles/templates/service-account.yaml. Both RoleBindings correctly reference these resources.apps/rabbitmq/values.yaml (1)
8-28: LGTM!The users list is well-structured with appropriate references to ConfigMaps and Secrets for each service. The key names align with the consuming template.
apps/rabbitmq/templates/init-rabbitmq-with-user.yaml (4)
11-24: Job metadata looks good; static analysis error is a false positive.The YAMLlint error on line 11 can be safely ignored—it doesn't understand Helm template syntax. The ArgoCD hook configuration and wave-based sync are appropriate for sequential user provisioning.
Note: The wave-based naming means Job names will change if the users list is reordered, which could cause ArgoCD to recreate Jobs. This is acceptable for PostSync hooks with HookSucceeded delete policy.
33-58: InitContainer pattern is sound.The initContainer correctly fetches credentials from the
faf-appsnamespace and prepares them for the main container. The use of base64 decode for secrets and file-based environment passing is appropriate for this Job pattern.
91-96: LGTM!The volume mount configuration and
restartPolicy: Neverare appropriate for a Job. The wave increment ensures sequential execution of user provisioning.
25-32: The RBAC configuration is already properly defined in the codebase. Theinit-appsServiceAccount exists in thefaf-appsnamespace with a RoleBinding granting access to theread-cm-secretsClusterRole, which permitsgetandlistoperations on ConfigMaps and Secrets—exactly matching what the initContainer requires.
| # ======================================= | ||
| # Jesus, what the fuck is happening here? | ||
| # ======================================= | ||
| # | ||
| # 1. Create a service account | ||
| # 2. Permit it to read configmaps and secrets in the faf-apps namespace | ||
| # 3. Iterate over the databasesAndUsers list and create a job for each database | ||
| # a) initContainer: Load the configmap and secret into environment variables. This must happen via k8s api, as we can't directly reference cm/secrets cross-namespace. | ||
| # b) actual container: Load the env from file and create the database and user | ||
|
|
There was a problem hiding this comment.
Replace unprofessional language in comments.
The comment on Line 2 contains profanity that is inappropriate for production code. Replace with professional language.
Apply this diff:
-# Jesus, what the fuck is happening here?
+# Complex cross-namespace RabbitMQ user provisioning pattern🤖 Prompt for AI Agents
In apps/rabbitmq/templates/init-rabbitmq-with-user.yaml around lines 1 to 10,
the top comment contains profanity; remove the unprofessional language and
replace it with a concise, professional header that describes the file’s purpose
(e.g., "Initialization steps for RabbitMQ users and databases" or similar), then
ensure the numbered bullet list remains clear and formal; simply update the
comment text to be professional and descriptive without changing the functional
content below.
| - | | ||
| set -a | ||
| . /config/env | ||
| set +a | ||
| vhost="/faf-core" | ||
| if rabbitmqadmin --format=bash --host=rabbitmq-0.rabbitmq.faf-apps.svc.cluster.local --username=$ADMIN_USER --password=$ADMIN_PASSWORD list vhosts | grep -q "$vhost"; then | ||
| echo "$vhost vhost alerady exists" | ||
| else | ||
| rabbitmqadmin --format=bash --host=rabbitmq-0.rabbitmq.faf-apps.svc.cluster.local --username=$ADMIN_USER --password=$ADMIN_PASSWORD declare vhost name="$vhost" | ||
| fi | ||
| if rabbitmqadmin --format=bash --host=rabbitmq-0.rabbitmq.faf-apps.svc.cluster.local --username=$ADMIN_USER --password=$ADMIN_PASSWORD list users | grep -q "$SYNC_USERNAME"; then | ||
| echo "$SYNC_USERNAME user alerady exists" | ||
| else | ||
| rabbitmqadmin --format=bash --host=rabbitmq-0.rabbitmq.faf-apps.svc.cluster.local --username=$ADMIN_USER --password=$ADMIN_PASSWORD declare user name="$SYNC_USERNAME" password="$SYNC_PASSWORD" tags="" | ||
| fi | ||
| rabbitmqadmin --format=bash --host=rabbitmq-0.rabbitmq.faf-apps.svc.cluster.local --username=$ADMIN_USER --password=$ADMIN_PASSWORD declare permission vhost="$vhost" user="$SYNC_USERNAME" configure=".*" read=".*" write=".*" | ||
There was a problem hiding this comment.
Fix typos and consider refactoring for readability.
Two issues identified:
- Typo: Lines 78 and 84 contain "alerady" which should be "already"
- Repetitive code: The
rabbitmqadmincommand with--host=rabbitmq-0.rabbitmq.faf-apps.svc.cluster.local --username=$ADMIN_USER --password=$ADMIN_PASSWORDis repeated 5 times. Consider extracting these into a function or variable.
Apply this diff to fix the typos and improve readability:
set -a
. /config/env
set +a
vhost="/faf-core"
+
+ # Helper function to reduce repetition
+ rabbitmq_admin() {
+ rabbitmqadmin --format=bash \
+ --host=rabbitmq-0.rabbitmq.faf-apps.svc.cluster.local \
+ --username=$ADMIN_USER \
+ --password=$ADMIN_PASSWORD \
+ "$@"
+ }
- if rabbitmqadmin --format=bash --host=rabbitmq-0.rabbitmq.faf-apps.svc.cluster.local --username=$ADMIN_USER --password=$ADMIN_PASSWORD list vhosts | grep -q "$vhost"; then
- echo "$vhost vhost alerady exists"
+ if rabbitmq_admin list vhosts | grep -q "$vhost"; then
+ echo "$vhost vhost already exists"
else
- rabbitmqadmin --format=bash --host=rabbitmq-0.rabbitmq.faf-apps.svc.cluster.local --username=$ADMIN_USER --password=$ADMIN_PASSWORD declare vhost name="$vhost"
+ rabbitmq_admin declare vhost name="$vhost"
fi
- if rabbitmqadmin --format=bash --host=rabbitmq-0.rabbitmq.faf-apps.svc.cluster.local --username=$ADMIN_USER --password=$ADMIN_PASSWORD list users | grep -q "$SYNC_USERNAME"; then
- echo "$SYNC_USERNAME user alerady exists"
+ if rabbitmq_admin list users | grep -q "$SYNC_USERNAME"; then
+ echo "$SYNC_USERNAME user already exists"
else
- rabbitmqadmin --format=bash --host=rabbitmq-0.rabbitmq.faf-apps.svc.cluster.local --username=$ADMIN_USER --password=$ADMIN_PASSWORD declare user name="$SYNC_USERNAME" password="$SYNC_PASSWORD" tags=""
+ rabbitmq_admin declare user name="$SYNC_USERNAME" password="$SYNC_PASSWORD" tags=""
fi
- rabbitmqadmin --format=bash --host=rabbitmq-0.rabbitmq.faf-apps.svc.cluster.local --username=$ADMIN_USER --password=$ADMIN_PASSWORD declare permission vhost="$vhost" user="$SYNC_USERNAME" configure=".*" read=".*" write=".*"
+ rabbitmq_admin declare permission vhost="$vhost" user="$SYNC_USERNAME" configure=".*" read=".*" write=".*"🤖 Prompt for AI Agents
In apps/rabbitmq/templates/init-rabbitmq-with-user.yaml around lines 70 to 90,
correct the typos "alerady" to "already" on the two echo lines and refactor the
repeated rabbitmqadmin invocation into a single reusable base command: define a
variable (e.g., host and base_cmd) that includes the common --host, --username
and --password flags, then replace the five repeated rabbitmqadmin calls to use
"$base_cmd <subcommand...>" (or a small helper function) to improve readability
and reduce duplication while keeping the same logic for checking/declaring the
vhost, user and permissions.
Summary by CodeRabbit
Chores
New Features
Bug Fixes
✏️ Tip: You can customize this high-level summary in your review settings.