Skip to content

chore: Set image tag to sha-aa058fb (JVM SDK 0.3.0) - #103

Merged
bbaarriiss merged 1 commit into
mainfrom
chore/set-image-tag-to-sha-aa058fb
Oct 5, 2026
Merged

bbaarriiss merged 1 commit into
mainfrom
chore/set-image-tag-to-sha-aa058fb

Conversation

@bbaarriiss

Copy link
Copy Markdown

Set image tag to sha-aa058fb (JVM SDK 0.3.0)

@bbaarriiss bbaarriiss self-assigned this Oct 5, 2026
@bbaarriiss
bbaarriiss requested a review from a team as a code owner October 5, 2026 12:35
@claude

claude Bot commented Oct 5, 2026

Copy link
Copy Markdown

Review — chore: Set image tag to sha-aa058fb (JVM SDK 0.3.0)

Single-line prod image tag bump. The diff itself is correct and I would approve it. Most of what follows is about the deploy path around it rather than the change.

What I verified

  • The tag is well-formed and points at the right commit. sha-aa058fb matches aa058fb = current main tip (chore: WPB-29049 Bump JVM SDK version to 0.3.0 (#102)), and the format matches what staging.yml produces via docker/metadata-action (type=sha,format=short → sha-<7 chars>).
  • No config drift at this version. The app requires DB_USER, DB_PASSWORD, DB_URL, SDK_APP_TOKEN, API_HOST_URL, CRYPTO_PASSWORD (EnvConfigVariables.kt + ConfigurationDependencyInjection.kt). All are supplied by values-prod.yaml plus the pollapp-secrets refs in statefulset.yaml. SDK_APP_TOKEN and CRYPTO_PASSWORD go through getEnvOrThrow, so a missing one is a hard boot failure — they are wired correctly, so no action needed, just confirming the bump needs no new keys.

Worth confirming before merge

  1. Does the image actually exist? The Build workflow on main must have pushed sha-aa058fb to quay.io/wire/poll-app. Nothing in this repo validates that, so a failed/skipped build (or a typo in the sha) surfaces only as ImagePullBackOff on a single-replica StatefulSet in prod.
  2. Staging soak. staging.yml deploys on every main push, so this exact sha has been in staging since PR 102 merged on Oct 1. This PR is the only gate before prod — worth stating in the description that staging has been healthy on it.
  3. SDK 0.3.0 and the persistent volume. The chart mounts the PVC at /app/storage, and the Dockerfile only does mkdir -p storage under WORKDIR /app — nothing in this repo sets that path, it relies on the SDK default. If 0.3.0 changed the default storage location or the on-disk format, the app would come up against an empty crypto store (silent re-registration) while the existing PVC content is orphaned. I could not reach the SDK release notes from this environment, so please confirm that is unchanged — the volume is ReadWriteOnce, single replica, and the chart has no backup of it.
  4. Rollback path. Flyway runs in-process at startup; the latest migration is V9__Add_results_visibility_toggle_column.sql and PR 102 does not appear to add one, so reverting this tag should be a clean rollback. Flagging it only because that stops being true the moment an SDK bump ships alongside a migration.

Suggestions (not blockers, mostly outside this diff)

  • Pin by digest, not tag. sha-aa058fb is a mutable Quay tag — a workflow_dispatch re-run on the same commit overwrites it with a different image, and prod would pick that up on the next pod restart with no diff anywhere. tag: "sha-aa058fb@sha256:..." (or a separate digest value) makes prod deploys reproducible. Cheap insurance for a prod-only values file.
  • Nothing in CI covers this file. pull-request.yml runs only ktlint/detekt/gradle build, so a YAML-only PR gets no real validation — the tests check running here is a build of unchanged Kotlin, not a signal about the deployed image. A helm lint + helm template -f values-prod.yaml step would catch indentation/key typos at PR time, and a registry existence check (skopeo inspect or the Quay API) would cover point 1.
  • Automate the bump. The TODO at the top of values-prod.yaml ("move this to argocd-integrations when ArgoCD is configured") is the real fix — manual bump PRs mean the file drifts silently from what is actually running if anyone deploys out-of-band.

Performance / security / tests

  • Performance: nothing introduced here. Tangentially: the entrypoint is a bare java -jar app.jar with no heap flags, so the JVM takes ~25% of the 512Mi limit (~128Mi heap). If 0.3.0 raised the SDK footprint, that is the ceiling that will bite first — worth watching pod memory after rollout.
  • Security: no secrets in the diff. Pre-existing and not introduced here, but values-prod.yaml hardcodes the prod Aurora endpoint and DB username in a public repo — not a credential, but useful recon. Moving the file to argocd-integrations resolves that too.
  • Tests: no app code changed, so nothing to add.

Nit: the commit headline is * Set image tag to sha-aa058fb (JVM SDK 0.3.0) — the leading * looks like a leftover bullet from a squash.

@bbaarriiss
bbaarriiss merged commit a252f47 into main Oct 5, 2026
5 checks passed
@bbaarriiss
bbaarriiss deleted the chore/set-image-tag-to-sha-aa058fb branch October 5, 2026 13:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants