Deploy Qodo using Helm

​

Where the chart comes from

helm registry login artifacts-self-hosted.qodo.ai \
  --username '<your-qodo-account-email>' \
  --password '<your-qodo-licence-id>'

​

1. Prerequisites

• Kubernetes 1.25+ and Helm 3, with a namespace you can install into.
• An ingress controller (any: ingress-nginx, GCE, Traefik, …) and a DNS record you control — see step 2.
• PostgreSQL. Nothing to prepare by default: the chart runs Postgres 16 with pgvector in-cluster, creates its own databases and generates its own admin password. To use your own database server instead — PostgreSQL 15 or 16 with the pgvector extension available — set externalDatabase.enabled: true and see step 5.
• A StorageClass that provisions PersistentVolumes (ReadWriteOnce is enough). Postgres, Redis, RabbitMQ and the Qodo Git repo cache each claim one. If your cluster has no dynamic provisioning at all, see Clusters without persistent volumes.
• Credentials Qodo issued you for the image registry.
• One identity provider for single sign-on (step 3): commercial Entra, GCC High (or another sovereign Microsoft cloud), Ping Identity, Okta, or Google Workspace. Each is a different global.entra entity — do not mix their fields.
• An LLM endpoint: an OpenAI-compatible URL and API key. It may be your own gateway; no outbound access to api.openai.com is required if you provide one.

​

2. DNS and TLS

• The resolved auth hostname must resolve from inside the cluster too. Pods validate sign-on tokens against that public OIDC issuer, so a record that only exists on your corporate DNS, or a split-horizon setup that resolves it differently inside, will fail after login rather than at install time.
• The webhook host must be reachable by whatever calls it. If your git provider is cloud-hosted, git.<baseDomain> needs to be reachable from the internet. You can serve webhooks on the base domain itself instead of a subdomain — set global.ingress.gitHostname — but the host you choose is also the URL handed to the provider when hooks are registered, so it must resolve and be covered by the certificate from the caller’s point of view.
• The SDK host defaults to sdk.<baseDomain>. If your DNS or certificate policy requires a different hostname, set global.ingress.sdkHostname; both the QAR Ingress route and the platform’s DYNACONF_SDK__BASE_URL are derived from that one value.

​

3. Identity provider (Entra, GCC High, Ping, Okta, or Google Workspace)

https://<resolved-auth-hostname>/ui/login/login/externalidp/callback
https://<resolved-auth-hostname>/idps/callback

​

Commercial Entra (type: entra)

1. Note the Application (client) ID and Directory (tenant) ID.
2. Create a client secret and copy its value.
3. Add both Redirect URIs above (type Web).

Register both. The sign-on service uses the first one; the second is required by its API. Registering only /idps/callback looks correct and fails at login with AADSTS50011: The redirect URI ... does not match the redirect URIs configured for the application.

global:
  entra:
    name: Corporate SSO
    type: entra
    clientId: "<Application (client) ID>"
    tenantId: "<Directory (tenant) ID>"
    existingSecret: qodo-entra-idp

​

GCC High (type: generic-oidc)

global:
  entra:
    name: Entra GCC High
    type: generic-oidc
    clientId: "<Application (client) ID>"
    tenantId: ""
    issuerUrl: "https://login.microsoftonline.us/<tenant-id>/v2.0"
    userClaimsSource: id_token
    existingSecret: qodo-entra-idp

​

Ping Identity (type: generic-oidc)

global:
  entra:
    name: Ping Identity
    type: generic-oidc
    clientId: "<Ping OIDC client ID>"
    tenantId: ""
    issuerUrl: "https://auth.pingone.<region>/<environment-id>/as"
    userClaimsSource: id_token
    existingSecret: qodo-ping-idp

​

Google Workspace (type: generic-oidc)

Fresh installations only. This procedure configures Google Workspace for a new Qodo and Zitadel installation. Switching an existing installation from another identity provider is an identity migration and account-linking project; that migration is not covered here.

1. Open Google Cloud Console → Google Auth Platform → Audience and confirm the user type is Internal. This is the access boundary: do not rely on the optional hd request parameter or claim.
2. Open Google Auth Platform → Clients, create an OAuth 2.0 Client ID, and choose Web application.
3. Add both resolved callback URIs:
   https://<resolved-auth-hostname>/ui/login/login/externalidp/callback
   https://<resolved-auth-hostname>/idps/callback
   
4. Copy the public client ID. Deliver the client secret through the customer-approved Kubernetes secret manager; never place it in this values file.
5. In Admin Console → Security → Access and data control → API controls → Third-party app access, a Workspace administrator locates the OAuth app by its client ID and sets an access status permitted by the customer’s policy. This is not domain-wide delegation, and the Admin Console does not create the OAuth client.

global:
  entra:
    name: Google Workspace
    type: generic-oidc
    clientId: "<Google OAuth client ID>"
    tenantId: ""
    issuerUrl: "https://accounts.google.com"
    userClaimsSource: id_token
    existingSecret: qodo-google-idp

1. The managed account must reach Qodo.
2. A fresh second login must reuse the same Qodo/Zitadel identity.
3. The outside account must be rejected by Google before Qodo creates a user.

• missing provisioning Secret: create the Secret in the Helm release namespace, ensure its name exactly matches global.entra.existingSecret, and ensure its key is exactly IDP_CLIENT_SECRET.
• invalid_client: verify that the client ID and Kubernetes Secret belong to the same Google OAuth client without printing the secret.
• redirect mismatch: compare both registered callback URIs exactly.
• an outside account reaches Qodo: stop rollout and change the Google OAuth audience to Internal.
• a duplicate user appears on the second login: stop rollout and investigate issuer/subject identity continuity.
• administrator controls are missing after promotion: sign out and obtain a fresh session, then verify the promoted email and workspace ID onprem-workspace.

​

Okta (type: generic-oidc)

global:
  entra:
    name: Okta
    type: generic-oidc
    clientId: "<oidc client id>"
    issuerUrl: "https://<org>.okta.com"
    userClaimsSource: userinfo
    existingSecret: qodo-entra-idp

​

Bootstrap a generic OIDC administrator

: "${NAMESPACE:?Set NAMESPACE to the Qodo Helm release namespace}"
kubectl -n "$NAMESPACE" exec -it deploy/qodo-platform -- \
  python -m modules.auth.scripts.promote_admin_cli \
    --email owner@example.com \
    --workspace-id onprem-workspace

​

Multiple identity providers

NAMESPACE=qodo
kubectl create secret generic qodo-entra-idps -n "$NAMESPACE" \
  --from-literal='DYNACONF_ZITADEL_PROVISION__EXTERNAL_IDPS=[{type="entra",name="Corporate",issuer_url="https://login.microsoftonline.com/<tenant-a>/v2.0",client_id="<client-a>",client_secret="<secret-a>"},{type="generic-oidc",name="GCC High",issuer_url="https://login.microsoftonline.us/<tenant-b>/v2.0",client_id="<client-b>",client_secret="<secret-b>"}]'

global:
  entra:
    name: ""
    clientId: ""
    tenantId: ""
    externalIdpsExistingSecret: qodo-entra-idps

​

4. Create the Secrets

On option B (the Qodo registry), skip Secret 1. A chart pulled with your licence already carries the registry credential and creates the pull Secrets itself.

# Pick your namespace once and reuse it in every command on this page.
NAMESPACE=qodo
kubectl create namespace "$NAMESPACE"

# 1. Image pull credentials (issued by Qodo). The name is fixed.
#    OPTION A ONLY — not needed when installing from the Qodo registry.
kubectl create secret docker-registry qodo-pull -n "$NAMESPACE" \
  --docker-server=artif-reg-self-hosted.codium.ai \
  --docker-username='<your-qodo-account-email>' \
  --docker-password='<your-qodo-license-id>'

# 2. LLM endpoint API key.
kubectl create secret generic qodo-openai -n "$NAMESPACE" \
  --from-literal=OPENAI_API_KEY='<api-key>'

# 3. Single-provider IdP client secret from section 3.
#    Enter the exact name from global.entra.existingSecret:
#      qodo-google-idp for the Google example;
#      qodo-ping-idp for the Ping Identity example;
#      qodo-entra-idp for the Entra, GCC High, and Okta examples.
#    Disable shell tracing before handling credentials.
set +x
read -rp "Identity provider Secret name: " IDP_SECRET_NAME
: "${IDP_SECRET_NAME:?Secret name is required}"
read -rsp "Identity provider client secret: " IDP_CLIENT_SECRET
echo
: "${IDP_CLIENT_SECRET:?Client secret is required}"
printf '%s' "$IDP_CLIENT_SECRET" |
  kubectl create secret generic "$IDP_SECRET_NAME" -n "$NAMESPACE" \
    --from-file=IDP_CLIENT_SECRET=/dev/stdin
unset IDP_CLIENT_SECRET IDP_SECRET_NAME

# 4. YOUR OWN DATABASE SERVER ONLY. Use that server's EXISTING admin
#    password (see step 5). Do not run this for bundled PostgreSQL: Helm
#    generates and owns qodo-db-admin when generatedSecrets.render=true.
kubectl create secret generic qodo-db-admin -n "$NAMESPACE" \
  --from-literal=POSTGRES_PASSWORD='<existing-database-admin-password>'

kubectl -n "$NAMESPACE" create secret generic qodo-telemetry-auth \
  --from-file=private-key.pem=./qodo-telemetry-auth/private-key.pem \
  --from-file=installation-id=./qodo-telemetry-auth/installation-id \
  --from-file=approval.json=./qodo-telemetry-auth/approval.json

telemetry:
  enabled: true
  mode: automatic       # on-demand or file are also supported
  pushInterval: 1h      # whole minutes/hours from 1m through 24h

kubectl -n "$NAMESPACE" port-forward deployment/qodo-telemetry 8091:8091
curl --fail http://127.0.0.1:8091/api/telemetry
curl --request POST --fail-with-body http://127.0.0.1:8091/api/telemetry/send
curl --fail --output qodo-telemetry-report.json \
  http://127.0.0.1:8091/api/telemetry/export

Do not pre-create qodo-db-admin on the bundled-PostgreSQL path. The chart renders that Secret as part of the Helm release; an existing Secret without Helm ownership metadata makes install fail with invalid ownership metadata. The exception is the fully pre-provisioned mode global.generatedSecrets.render=false, where you must create every Secret in the generated-credentials inventory before install.

​

5. Database

global:
  externalDatabase:
    host: qodo-postgres        # the in-cluster Service — leave as-is
    adminUser: postgres        # in-cluster superuser — correct here
    sslMode: disable           # the bundled server does not enable TLS
    existingSecret: qodo-db-admin
postgres:
  enabled: true                # brings the server up

​

Only if you bring your own database server

global:
  externalDatabase:
    enabled: true
    host: <your-db-host>
    adminUser: <admin user>          # see the warning below
    sslMode: require                 # encrypted; the managed-server default
    existingSecret: qodo-db-admin

CREATE DATABASE rag_db OWNER qodo_admin;      -- skip if it already exists
CREATE DATABASE qodo_rules OWNER qodo_admin;  -- skip if it already exists
ALTER DATABASE rag_db OWNER TO qodo_admin;
ALTER DATABASE qodo_rules OWNER TO qodo_admin;
\c rag_db
CREATE EXTENSION IF NOT EXISTS vector;
\c qodo_rules
CREATE EXTENSION IF NOT EXISTS vector;

​

Clusters without persistent volumes

helm upgrade --install qodo ./qodo-onprem -n qodo \
  -f onprem-base.yaml -f my-values.yaml -f qodo-onprem/values-emptydir.yaml

This destroys data. An emptyDir lives and dies with its pod. Any restart, eviction, node drain, or helm upgrade that rolls a pod wipes that component — the databases included. Verified, not theoretical: deleting the Postgres pod took the database count from 10 back to 5 and dropped a test table. Use it for a short-lived evaluation, never for an environment whose data matters, and expect to re-run onboarding after any restart.

Error: UPGRADE FAILED: cannot patch "qodo-rabbitmq" with kind StatefulSet:
  StatefulSet.apps "qodo-rabbitmq" is invalid: spec: Forbidden: updates to
  statefulset spec for fields other than 'replicas', 'ordinals', 'template',
  'updateStrategy', 'persistentVolumeClaimRetentionPolicy' and
  'minReadySeconds' are forbidden

kubectl delete deploy qodo-gitway -n <namespace>

kubectl delete pvc qodo-gitway-repo-store -n <namespace>

​

Only if you bring your own Redis

global:
  externalRedis:
    host: <your-redis-host>

kubectl -n qodo create secret generic qodo-redis-auth \
  --from-literal=REDIS_PASSWORD='<password>'

global:
  externalRedis:
    host: <your-redis-host>
    existingSecret: qodo-redis-auth

​

6. Write your values file

global:
  baseDomain: qodo.example.com
  ingress:
    className: nginx
    annotations:
      cert-manager.io/cluster-issuer: letsencrypt
  entra:
    name: Corporate SSO
    type: entra
    clientId: <application-client-id>
    tenantId: <directory-tenant-id>
  # GCC High instead of commercial Entra:
  # entra:
  #   name: Entra GCC High
  #   type: generic-oidc
  #   clientId: <application-client-id>
  #   issuerUrl: https://login.microsoftonline.us/<tenant-id>/v2.0
  #   userClaimsSource: id_token
  # Okta instead of Entra — pin a qodo-platform image that honors
  # IDP_USER_CLAIMS_SOURCE:
  # entra:
  #   name: Okta
  #   type: generic-oidc
  #   clientId: <okta-oidc-client-id>
  #   issuerUrl: https://<org>.okta.com
  #   userClaimsSource: userinfo
  llm:
    openaiBaseUrl: https://llm-gateway.example.internal/v1

global:
  externalDatabase:
    enabled: true                    # without this the other keys are ignored
    host: postgres.example.internal
    adminUser: qodo_admin
    existingSecret: qodo-db-admin

​

Rules embedding dimensions

platform:
  env:
    DYNACONF_RULES__AI__SIMILARITY__EMBEDDING_MODEL_NAME:
      value: "nomic-embed-text-v1"
    DYNACONF_RULES__AI__SIMILARITY__EMBEDDING_DIM:
      value: "768"
    DYNACONF_RULES__AI__SIMILARITY__EMBEDDING_SEND_DIMENSIONS:
      value: "false"
git-event-consumer:
  env:
    DYNACONF_RULES__AI__SIMILARITY__EMBEDDING_MODEL_NAME:
      value: "nomic-embed-text-v1"
    DYNACONF_RULES__AI__SIMILARITY__EMBEDDING_DIM:
      value: "768"
    DYNACONF_RULES__AI__SIMILARITY__EMBEDDING_SEND_DIMENSIONS:
      value: "false"

​

PR history embedding dimensions

engine-indexer:
  env:
    PR_KNOWLEDGE__EMBEDDING_DIMENSION:
      value: "1024"
    ONPREM_MODELS__REMOTE_RAG__EMBED_DIM:
      value: "1024"
engine-pr-kn-consumer:
  env:
    PR_KNOWLEDGE__EMBEDDING_DIMENSION:
      value: "1024"
    ONPREM_MODELS__REMOTE_RAG__EMBED_DIM:
      value: "1024"
engine-retriever:
  env:
    PR_KNOWLEDGE__EMBEDDING_DIMENSION:
      value: "1024"
    ONPREM_MODELS__REMOTE_RAG__EMBED_DIM:
      value: "1024"

ALTER TABLE pr_description_embedding    ALTER COLUMN embedding TYPE vector(1024);
ALTER TABLE pr_fix_suggestion_embedding ALTER COLUMN embedding TYPE vector(1024);

​

Optional per-user GitHub repository access

global:
  repositoryAccess:
    enabled: true
    filteringEnabled: false

​

7. Install

helm upgrade --install qodo ./qodo-onprem \
  --namespace "$NAMESPACE" \
  -f onprem-base.yaml \
  -f my-values.yaml

helm pull oci://artifacts-self-hosted.qodo.ai/codium-stack/qodo-onprem/qodo-onprem \
  --version <chart-version> --untar

helm upgrade --install qodo ./qodo-onprem \
  --namespace "$NAMESPACE" \
  -f qodo-onprem/onprem-base.yaml \
  -f my-values.yaml

kubectl get pods -n "$NAMESPACE" -w

​

Pulling the images from your own registry

global:
  imageProxyPrefix: registry.internal.example/qodo/

helm upgrade --install qodo ./qodo-onprem \
  --namespace "$NAMESPACE" \
  -f onprem-base.yaml -f my-values.yaml

helm template qodo ./qodo-onprem -f onprem-base.yaml -f my-values.yaml \
  | grep -o 'image: .*' | grep -v 'registry.internal.example'

​

Confining Qodo to particular nodes

global:
  # ADDED to the architecture pin, which you do not repeat.
  nodeSelector:
    your-pool-label: qodo
  # Needed if those nodes are tainted.
  tolerations:
    - key: dedicated
      operator: Equal
      value: qodo
      effect: NoSchedule
  # For placement a selector cannot express.
  affinity:
    nodeAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
        - weight: 100
          preference:
            matchExpressions:
              - key: topology.kubernetes.io/zone
                operator: In
                values: [us-central1-a]

kubectl get pods -n "$NAMESPACE" -o wide
kubectl get pods -n "$NAMESPACE" --field-selector status.phase=Pending

​

Clusters that require pods to declare their IDs

global:
  podSecurityContext:        # Pod-level fields
    runAsNonRoot: true
    runAsUser: 1000680000    # from YOUR namespace's assigned range
    runAsGroup: 1000680000
    fsGroup: 1000680000
  containerSecurityContext:  # container-level fields
    allowPrivilegeEscalation: false
    capabilities:
      drop: [ALL]

kubectl get namespace "$NAMESPACE" \
  -o jsonpath='{.metadata.annotations.openshift\.io/sa\.scc\.uid-range}{"\n"}'

​

8. Verify

# All workloads ready, setup jobs Completed
kubectl get pods -n "$NAMESPACE"

# The ingress has an address
kubectl get ingress -n "$NAMESPACE"

​

Troubleshooting

kubectl describe pod <pod> -n <namespace> | grep -A4 'Last State'

pr-agent-litegit:
  deployments:
    resources:
      limits:
        memory: 16Gi
      requests:
        memory: 16Gi
pr-agent-agentic:
  deployments:
    resources:
      limits:
        memory: 16Gi
      requests:
        memory: 8Gi

​

Upgrades

kubectl --namespace <namespace> scale deployment/qodo-git \
  deployment/qodo-pr-agent-agentic --replicas=0

kubectl -n <namespace> logs job/qodo-rabbitmq-topology-migrate

​

Argo CD / ApplicationSet (external PostgreSQL)

python3 qodo-onprem/verify-external-secrets.py \
  --context "$KUBE_CONTEXT" --namespace "$NAMESPACE"

1. Pin the release name to qodo, the same namespace and customer values, and a reviewed chart version. Keep the values order onprem-base.yaml, customer file, values-argocd.yaml. If the customer file lives in another Git repository, use Argo CD multi-source $values/... for that middle entry. Keep the Argo CD Application name qodo too, or configure a separate Argo CD tracking label key: Argo CD’s default app.kubernetes.io/instance rewrite can otherwise break this chart’s selectors.
2. Back up and import the existing bytes of every Secret above into the external Secret source, including Zitadel’s master key, LiteGit’s vault master key, and the database password. Preserve qodo-zitadel-generated. Never regenerate those keys against existing databases. Keep backup/export material only in approved encrypted Secret storage, never a values file, shell transcript, PR, or temporary render.
3. Have the external controller reconcile first. Run the preflight above with --require-zitadel-generated; verify its output is green, and verify the old and newly managed Secret data are byte-identical in your Secret system. Do not delete and recreate a live Secret to transfer its ownership. If only the pr-agent TOML check fails, reconstruct that file from the existing Platform bearer in the Secret source; do not rotate the bearer or its allowlist to match a stale TOML copy.
4. Freeze direct Helm upgrades. Start the ApplicationSet with automated pruning and self-heal off, inspect argocd app diff, and confirm Qodo’s credential Secrets are not in its desired manifest. Do not run helm uninstall: that deletes other live resources and is not an Argo CD adoption step. The old Helm release record can remain while Argo CD owns future reconciliation. Only one controller should write the workloads.
5. Sync in a maintenance window if the chart or images move. Argo CD waits for the chart’s ordered Jobs: wave -3 prepares static prerequisites/RBAC and waits for bundled RabbitMQ and Redis to be healthy; wave -2 checks RabbitMQ topology and initializes databases; wave -1 runs migrations; wave 0 updates workloads and provisions Zitadel; PostSync stamps the revision. The RabbitMQ Job checks the running broker on both install and upgrade. Absent queues on a fresh broker need no migration; a missing publisher alone does not prove retained queues are absent. Completed Jobs have stable names for identical renders and remain present; a chart, values, or queue-script change gives them new names and reruns them. Replicated pull-credential rotation alone does not change those names. Use a full Application sync, not selective resource sync: Argo CD skips hooks during selective sync, including this chart’s PostSync revision roll. Also disable ApplyOutOfSyncOnly=true: the topology Job can pause a workload whose manifest was unchanged at the start of the sync. Later waves must apply every Deployment to restore its configured replicas; argocd-upgrade-check.py pre rejects this selective-apply policy.
6. Check every migration Job and Deployment is healthy before enabling automatic sync/pruning. If you enable pruning, use PruneLast=true and keep the external Secret resources in their own Application/Secret controller with a deliberate retention policy. Never let pruning remove a credential the Qodo chart no longer renders. Before enabling self-heal, tell the Application to ignore the annotations that Qodo’s provision/revision Jobs maintain (including preparation markers retained across a Helm handoff), and set RespectIgnoreDifferences=true:
   spec:
     ignoreDifferences:
       - group: apps
         kind: Deployment
         jqPathExpressions:
           - '.spec.template.metadata.annotations."qodo.ai/revision"'
           - '.spec.template.metadata.annotations."qodo.ai/zitadel-idp-config"'
           - '.spec.template.metadata.annotations."qodo.ai/ca-bundle-checksum"'
           - '.metadata.annotations."qodo.ai/consumer-prepared-upgrade"'
           - '.spec.template.metadata.annotations."qodo.ai/consumer-preparation-recovery"'
     syncPolicy:
       syncOptions:
         - RespectIgnoreDifferences=true
         - PruneLast=true
   
   Without that policy, Argo CD can undo the Jobs’ pod restarts and repeatedly report drift. This Application policy belongs in the ApplicationSet, not in Helm values; validate it in the actual generated Application before turning on self-heal.

​

Check before and after every Argo CD sync

python3 qodo-onprem/argocd-upgrade-check.py pre --context "$KUBE_CONTEXT" \
  --namespace "$NAMESPACE" --argo-namespace "$ARGO_NAMESPACE" --app qodo
# sync only when it reports GO, then:
python3 qodo-onprem/argocd-upgrade-check.py post --context "$KUBE_CONTEXT" \
  --namespace "$NAMESPACE" --argo-namespace "$ARGO_NAMESPACE" --app qodo \
  --revision "$CHART_VERSION"

• an operation is running or queued, or automated sync is on;
• the Application’s comparison is stale or failed, or its desired state contains a credential Secret;
• a credential Secret is missing, or one that the Application tracks lacks Prune=false;
• a running pod’s environment or mounted pr-agent TOML differs from its Secret;
• RabbitMQ or the bundled LLM gateway rejects the Secret’s value;
• Zitadel logs master-key decrypt errors or database login failures;
• any of these checks cannot run (missing access, unreadable container, no running pods).

​

Moving an Argo CD install off generatedSecrets.render: true

• The diff doesn’t show it. ignoreDifferences on Secret data hides the change from the diff but not from the sync.
• RespectIgnoreDifferences doesn’t stop it when it covers only /data, because the chart renders stringData.
• The servers keep the old values. RabbitMQ keeps the password it stored on first boot. Zitadel’s master key encrypts its stored keys, and LiteGit’s vault key encrypts provider credentials, so the old values stay authoritative there.
• Running pods keep working until they restart. An upgrade restarts all of them, and then RabbitMQ logins, Zitadel and Git integrations fail together.

1. Turn off automated sync and make sure no operation is running.
2. Run the pre check. If secrets.match_running_pods, rabbitmq.accepts_secret or zitadel.credentials fails, the Secrets no longer hold the values the servers use.
3. Recover the original bytes from your own backup, or from the newest Helm release record in the namespace (sh.helm.release.v1.qodo.v<N>, written by the last direct helm install or helm upgrade). Put them back into the six generated credential Secrets and qodo-pr-agent-secrets-toml. Restore Zitadel’s master key and LiteGit’s vault key exactly: regenerating them loses the data they protect.
4. The database setup Job resets the zitadel role’s password whenever it runs. If the role rejects the restored ZITADEL_DB_PASSWORD, set it from a database admin session with ALTER ROLE zitadel PASSWORD. If RabbitMQ rejects every candidate, set the broker to the Secret’s value with rabbitmqctl change_password qodo instead of generating a new one.
5. Annotate the Secrets argocd.argoproj.io/sync-options: Prune=false and restart the Qodo Deployments so every pod reads the restored values. Repeat the pre check until it reports GO.

1. Scale qodo-litegit (the publisher) to 0.
2. Wait until vcs-events.pr-agent-pro-__pass_through__ and vcs-events.qodo-platform-rules-consumer show 0 messages (rabbitmqctl list_queues name messages).
3. Delete those two queues with rabbitmqctl delete_queue.

​

Argo CD operations during an upgrade

• Argo CD runs one operation per Application at a time. While a sync waits for an unhealthy resource, later sync requests queue behind it. Terminate the operation and wait for a terminal phase before syncing again.
• Argo CD before 3.3.15, 3.4.9 and 3.5.3 can replay the previous result, without applying anything, when a sync is started by writing the Application’s operation field directly (scripts, kubectl patch). Syncs started from the Argo CD UI or CLI are not affected. This is argoproj/argo-cd#26530, fixed by #28778. After any scripted sync, check that the operation’s start time changed.
• Do not use “apply only” (skip hooks) or a selective sync to get past a failing step. Both skip the RabbitMQ topology migration and the revision roll, so the workloads move to the new version without them.
• If the RabbitMQ topology Job reports rejected user 'qodo' (HTTP 401), the password in qodo-rabbitmq-password does not match the broker. Fix the credential as described above; syncing again cannot.
• Any chart or values change gives every setup and migration Job a new name, so all of them run again. The previous revision’s Jobs then show as “requires pruning”. Remove them with a pruning sync (PruneLast=true) once every tracked credential Secret carries Prune=false, or delete them by hand.

​

Azure SAML with Login V1