chore: Update tag to deploy on production (sha-9efe83d)

[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-9efe83d)

One-line release promotion — no application code involved, so this is mostly a correctness/process check.

✅ What checks out

• The tag matches the intended commit. origin/main HEAD is 9efe83daff364b6e4239ade1aaf8a9c70b6726a9, so sha-9efe83d is the short SHA of the commit merged in fix: Fix 2 template properties deserialization WPB-28090 #138 (fix: Fix 2 template properties deserialization WPB-28090).
• Tag format matches what CI publishes. .github/workflows/staging.yml uses docker/metadata-action with type=sha,format=short, which produces exactly sha-<7-char> — so the value in values-prod.yaml:4 is the right shape.
• Scope is minimal and reviewable, and the previous tag (sha-545c536) stays in git history, so a rollback is a plain git revert of this commit. Nothing sensitive in the diff; prod secrets still come from the external secret referenced in values.yaml.

🔍 Worth confirming / suggestions

1. Confirm the image tag actually exists in Quay before merging (I couldn't reach the registry from this environment). staging.yml guards the build with if: github.actor != 'github-actions[bot]', so any main push authored by the bot publishes no image. fix: Fix 2 template properties deserialization WPB-28090 #138 was merged by a human, so it almost certainly built — but the guard means a promotion PR can silently point prod at a non-existent tag and land in ImagePullBackOff. A cheap preflight job on PRs touching helm/** would close that hole permanently:

   - name: Verify image tag exists
     run: |
       TAG=$(yq '.image.tag' helm/githubapp/values-prod.yaml)
       skopeo inspect "docker://quay.io/wire/github-app:${TAG}" > /dev/null

2. DEPLOYMENT.md now contradicts this workflow. helm/githubapp/DEPLOYMENT.md 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", yet this PR pins the prod tag in-repo. Also, nothing in this repo reads values-prod.yaml (grep finds zero references outside the file itself). Two things worth clarifying:

   • If values-prod.yaml became the source of truth in feat: Production k8s deploy #WPB-27713 #134, DEPLOYMENT.md should be updated in the same breath — otherwise the next person promotes a release in the wrong repo.
   • If ArgoCD ImageUpdater is still active for prod, a manually pinned tag here can be overwritten by the updater (or vice versa), producing surprising drift. Stating explicitly which mechanism owns the prod image tag would help.

3. Consider pinning by digest for prod. sha-9efe83d is a mutable tag — a re-run of the build for the same commit can move it. quay.io/wire/github-app@sha256:… makes prod deploys byte-for-byte reproducible; the short SHA can stay in the PR title/body for readability.

4. Chart version/appVersion are still 0.0.1 (Chart.yaml:5-6) while the deployed image changes every release. If anything downstream keys off chart version, releases look identical. Either bump on promotion, or add a one-line note in DEPLOYMENT.md that the chart version is intentionally static because ArgoCD tracks the git revision.

5. CI signal is a bit off-target for this PR. pull-request.yml runs ktlintCheck + detekt + full ./gradlew build on a YAML-only change, while the Helm chart itself gets no validation at all. A helm lint / helm template -f values-prod.yaml job (plus paths filters so the JVM checks only run for src/**) would give the checks that actually matter here.

6. Traceability nit: the body says "New version will be deployed to production" — linking the promoted commit/PR (fix: Fix 2 template properties deserialization WPB-28090 #138) and the diff since sha-545c536 makes the prod audit trail readable straight from the PR.

Tests

No test changes needed for a tag bump. The gap is at the pipeline level rather than the unit level: items 1 and 5 above are the ones that would catch a bad promotion.

Verdict: the tag value is correct and this looks safe to merge once the Quay tag is confirmed present. Items 2–5 are follow-ups for the release process rather than blockers on this PR.