chore: Update production image tag (sha-0bf7e0e)

[bbaarriiss]

Update tag to deploy on production (sha-0bf7e0e)

[claude]

Review — chore: Update production image tag (sha-0bf7e0e)

The change itself looks correct. 0bf7e0e is the current main HEAD (chore: Bump app version to 0.2.0 (#148)), and the tag format matches what staging.yml publishes (docker/metadata-action with type=sha,format=short → sha-<7-char-sha>). Single-line, well-scoped, consistent with the previous bumps (#137, #139).

A few things worth checking or following up on — none of them are blockers for the tag value itself.

1. Confirm the image actually exists before merging (blocking-ish)

staging.yml is gated on if: github.actor != 'github-actions[bot]'. If #148 landed via automation rather than a human merge, no image was built for 0bf7e0e and the prod rollout will sit in ImagePullBackOff — the StatefulSet has no fallback (helm/githubapp/templates/statefulset.yaml:33 only falls back to .Chart.AppVersion when image.tag is empty, not when the pull fails). Please confirm the Staging run for 0bf7e0e succeeded and quay.io/wire/github-app:sha-0bf7e0e is present before merging. I could not reach quay.io or the Actions API from the review sandbox to verify this myself.

2. Chart.yaml is stale

Chart.yaml still has version: 0.0.1 / appVersion: "0.0.1" while the app is now 0.2.0 (build.gradle.kts:14). Two consequences:

• appVersion is the fallback in statefulset.yaml:33, so any install that does not override image.tag (the base values.yaml does not set one) resolves to quay.io/wire/github-app:0.0.1 — a tag that likely does not exist.
• A chart version that never changes means chart-level changes are not distinguishable to Helm/ArgoCD by version.

Not this PR's job to fix, but bumping appVersion alongside app releases would be a cheap improvement.

3. Docs vs. reality

helm/githubapp/DEPLOYMENT.md says "values for each environment are in the argocd-integrations repo" and that ArgoCD ImageUpdater triggers deploys when new images are published — yet values-prod.yaml lives here and is bumped by hand. It is unclear from the repo which is the source of truth for prod. Worth updating DEPLOYMENT.md to describe the actual flow, otherwise the next person will look in the wrong repo.

4. Test coverage gap for this class of change

pull-request.yml only runs ktlintCheck / detekt / build — nothing validates the Helm chart. A typo'd sha, malformed YAML, or a broken template in values-prod.yaml would pass CI and fail at deploy time. A cheap guard would be a job triggered on helm/** changes:

- run: helm lint helm/githubapp -f helm/githubapp/values-prod.yaml
- run: helm template helm/githubapp -f helm/githubapp/values-prod.yaml > /dev/null

plus optionally a skopeo inspect docker://quay.io/wire/github-app:$TAG step asserting the referenced image exists. That turns the failure mode in item 1 into a red CI check instead of a broken prod pod.

5. Nice-to-haves

• Describe what is shipping. The description only restates the sha. Prod has been on sha-9efe83d since Aug 27, so this rolls up everything merged since then. A short changelog in the body helps whoever is on call correlate a regression to this deploy.
• Digest pinning. Quay tags are mutable; sha-* tags are immutable only by convention. Pinning by digest (@sha256:...) would be strictly stronger, though it is a readability trade-off and clearly out of scope here.

Security / performance

Nothing of concern. No secrets in the diff — the env values in values-prod.yaml are non-sensitive config, and secrets come from the external-secrets mount. Resource limits and probes are unchanged. pullPolicy: IfNotPresent is fine given the tag changes on every deploy.

Verdict: LGTM on the diff, pending confirmation that sha-0bf7e0e was actually pushed to quay.io (item 1). Items 2–5 are follow-ups, not merge blockers.