chore: Update tag to deploy on production sha-545c536

[bbaarriiss]

New version will be deployed to production.
In this PR, we set the latest tag in values-prod.yaml file.

[claude]

Review — chore: Update tag to deploy on production sha-545c536

One-line image tag bump in helm/githubapp/values-prod.yaml. LGTM — nothing blocking. Here's what I verified and a few non-blocking notes.

Verified ✅

• Tag format matches CI output. .github/workflows/staging.yml uses docker/metadata-action with type=sha,format=short and flavor: latest=false, which produces exactly sha-<7-char-sha> — so sha-545c536 is the right shape.
• The sha is a real commit on main. 545c536bb9141781f39e2affe009f5cdfd9d8967 = merge commit of chore: Update closed and opened templates to have compact look #136 ("Update closed and opened templates to have compact look"), merged 2026-08-14 by a human account — so the Build workflow's if: github.actor != 'github-actions[bot]' guard passed and the image should have been published.
• No accompanying config changes needed. I cross-checked every variable in src/main/kotlin/com/wire/github/util/EnvironmentVariables.kt (GHAPP_SERVER_PORT, GHAPP_API_HOST, GHAPP_REDIS_URL, WIRE_SDK_APP_ID, WIRE_SDK_API_TOKEN, WIRE_SDK_API_HOST, WIRE_SDK_CRYPTOGRAPHY_STORAGE_PASSWORD) against values-prod.yaml plus the secret/redis refs in templates/statefulset.yaml. All are covered; chore: Update closed and opened templates to have compact look #136 touched only message templates, so there is no new config surface.
• imagePullPolicy: IfNotPresent (values.yaml) is fine here, since each deploy uses a distinct immutable-by-convention sha tag rather than a floating one.

I could not confirm from this environment that quay.io/wire/github-app:sha-545c536 actually exists in the registry (no outbound network access in the review sandbox), so please eyeball the Build run for 545c536 before merging — a missing tag surfaces only as ImagePullBackOff after the fact.

Non-blocking notes

1. DEPLOYMENT.md contradicts this PR's workflow. It says "values for each environment are in the argocd-integrations repo" and "that repo uses ArgoCD with an ImageUpdater to trigger deploys when new images are published" — but this PR manually pins a tag in an in-repo values-prod.yaml. Either the in-repo file is authoritative now (and the doc is stale), or it is vestigial (and someone will eventually edit it expecting a deploy that never happens). Worth a one-line doc update saying which file is the real source of truth, and whether ImageUpdater still writes tags.
2. Consider pinning by digest for prod. tag: "sha-545c536" is a mutable reference — a tag can be overwritten or deleted in the registry, and 7-hex-char abbreviations are not collision-proof in principle. image.digest: "sha256:…" (or tag@digest) gives a cryptographically pinned artifact and makes rollbacks unambiguous. Low priority given the internal, single-writer registry, but it is the standard hardening for a production pin.
3. Chart.yaml stays at version: 0.0.1 / appVersion: "0.0.1" across every deploy. Harmless if ArgoCD tracks this chart from Git, but if it is ever pulled from a Helm repo, a never-changing chart version invites cached/stale renders. Bumping appVersion alongside the tag would also make "what's in prod" readable from the chart alone.
4. Only prod is pinned in-repo — there is no values-staging.yaml, so there is no way to tell from this repo what staging is currently running, i.e. no way to confirm this build was soak-tested before promotion. If staging values live in argocd-integrations, note that in DEPLOYMENT.md so the promotion path is discoverable.
5. Small CI fragility (not this PR's problem). Because Build skips when github.actor == 'github-actions[bot]', any bot-merged commit to main (Dependabot auto-merge, or an automated deploy-PR merge) publishes no image. A future tag bump onto such a sha would point at a nonexistent tag. A cheap guard: have the deploy-PR job assert the tag exists in Quay before opening the PR, or add a CI check on this PR that does a skopeo inspect / Quay tag lookup for the tag being introduced.

Code quality / tests / performance / security

Nothing to assess — no application code, no logic, no new tests warranted. No secrets or credentials are introduced; values-prod.yaml correctly keeps WIRE_SDK_API_TOKEN, WIRE_SDK_CRYPTOGRAPHY_STORAGE_PASSWORD, and GHAPP_REDIS_URL out of plaintext values and sourced from secretKeyRef. Rollback is a one-line revert back to sha-6bd8f51, which the diff conveniently records.

Note: this repo has no CLAUDE.md, so I reviewed against the conventions visible in the Helm chart and CI workflows.