[alexandreferris]

---

PR Submission Checklist for internal contributors

• The PR Title

  • conforms to the style of semantic commits messages¹ supported in Wire's Github Workflow²
  • contains a reference JIRA issue number like SQPIT-764
  • answers the question: If merged, this PR will: ... ³

• The PR Description

  • is free of optional paragraphs and you have filled the relevant parts to the best of your ability

---

What's new in this PR?

Issues

Briefly describe the issue you have solved or implemented with this pull request. If the PR contains multiple issues, use a bullet list.

Causes (Optional)

Briefly describe the causes behind the issues. This could be helpful to understand the adopted solutions behind some nasty bugs or complex issues.

Solutions

Briefly describe the solutions you have implemented for the issues explained above.

Dependencies (Optional)

If there are some other pull requests related to this one (e.g. new releases of frameworks), specify them here.

Needs releases with:

• GitHub link to other pull request

Testing

Test Coverage (Optional)

• I have added automated test to this contribution

How to Test

Briefly describe how this change was tested and if applicable the exact steps taken to verify that it works as expected.

Notes (Optional)

Specify here any other facts that you think are important for this issue.

Attachments (Optional)

Attachments like images, videos, etc. (drag and drop in the text box)

---

PR Post Submission Checklist for internal contributors (Optional)

• Wire's Github Workflow has automatically linked the PR to a JIRA issue

---

PR Post Merge Checklist for internal contributors

• If any soft of configuration variable was introduced by this PR, it has been added to the relevant documents and the CI jobs have been updated.

---

References

1. https://sparkbox.com/foundry/semantic_commit_messages
2. https://github.com/wireapp/.github#usage
3. E.g. feat(conversation-list): Sort conversations by most emojis in the title #SQPIT-764.

[claude]

Review: chore: Bump sha commit

Single-line change bumping the prod image tag in helm/githubapp/values-prod.yaml from sha-0bf7e0e -> sha-3a9c9d7. The change itself looks correct; a few notes below.

Correctness

• The 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>. ✔
• 3a9c9d7 is the tip of main at the time this PR was opened, so it is a real commit. ✔
• image.repository is unchanged and consistent with values.yaml. ✔

One thing to confirm before merge: that the Staging workflow run for 3a9c9d7 completed and actually pushed quay.io/wire/github-app:sha-3a9c9d7. Since this is a brand-new tag, pullPolicy: IfNotPresent (values.yaml:5) offers no protection — if the push did not happen, prod lands in ImagePullBackOff rather than staying on the old image.

Docs inconsistency worth reconciling

helm/githubapp/DEPLOYMENT.md says:

Helm charts are here, while values for each environment are in the argocd-integrations repo.
That repo uses ArgoCD with an ImageUpdater to trigger deploys when new images are published.

But values-prod.yaml lives in this repo with a hand-pinned tag, and nothing in .github/ or README.md references it. Either the doc is stale, or this file is not the one driving prod — in which case this PR gives a false sense of having deployed something. If ArgoCD Image Updater also writes tags, the two sources can drift apart. A one-line doc update clarifying the source of truth for prod would help.

Suggestion: make the bump verifiable in CI

Manual 7-char SHA edits are easy to typo, and the failure only surfaces at rollout time. A cheap guard on PRs touching values-prod.yaml:

- name: Verify prod image tag exists
  run: |
    tag=$(yq -r '.image.tag' helm/githubapp/values-prod.yaml)
    repo=$(yq -r '.image.repository' helm/githubapp/values-prod.yaml)
    skopeo inspect "docker://${repo}:${tag}" > /dev/null

That turns "did the image get built?" from a post-merge prod incident into a red check. Optional, but it pays for itself the first time a SHA is off by a character.

Rollout expectation (not a blocker)

The workload is a StatefulSet with replicaCount: 1 and a single ReadWriteOnce PVC mounted via persistentVolumeClaim (templates/statefulset.yaml). A tag bump therefore terminates the old pod before the new one can attach the volume and start, so expect a short unavailability window plus startup-probe delay rather than a zero-downtime rolling update. Fine for a chore bump, just worth knowing it is not seamless.

PR hygiene

The description is still the unfilled template and the checklist boxes (including the JIRA reference the repo checklist asks for) are unticked. For a prod tag bump this diff is effectively the deploy record, so the most valuable addition is what is going to prod — e.g. the commit list for 0bf7e0e...3a9c9d7. That also documents the rollback target (sha-0bf7e0e) for whoever is on call. A title like chore(deploy): Bump prod image to sha-3a9c9d7 #SQPIT-xxx would be more self-describing than "Bump sha commit".

Security / test coverage

Nothing applicable — no application code, no new config variables or secrets, no change to ingress/TLS or RBAC. Optional hardening for later: pinning by digest (@sha256:...) instead of a sha- tag would make prod pins truly immutable, since tags stay mutable in the registry.

---

Verdict: LGTM pending confirmation that sha-3a9c9d7 is published to Quay. The docs inconsistency and the CI tag check are follow-ups, not blockers for this PR.