chore: WPB-24733 Integrate Poll App to ArgoCd

[bbaarriiss]

• Remove values-staging.yaml. (The file is moved to Argocd-integrations project)
• Add staging GitHub workflow to trigger deployment to staging on every push to main branch

[claude]

PR Review: WPB-24733 Integrate Poll App to ArgoCD

Thanks for setting this up! The change is small and focused: remove values-staging.yaml (now owned by the Argocd-integrations project) and add a workflow that builds + pushes the image to Quay on every push to main. The Docker build is self-contained (the multi-stage Dockerfile runs the Gradle build), so the pipeline is correct as written. A few suggestions below.

Code quality / best practices

• Duplicate workflow name. staging.yml is name: Build, identical to pull-request.yml. Two workflows sharing a display name is confusing in the Actions UI and in status checks. Consider name: Deploy to Staging or Build & Push (staging).
• Large commented-out block. Lines 38–63 leave the Helm-tag-update and commit-back logic commented out. Committed dead code tends to rot and confuse future readers; since it's in git history anyway, I'd remove it and re-add when ArgoCD is wired up (or capture the intent in the ticket). Note the commented sed still references helm/pollapp/values-staging.yaml, which this same PR deletes — so it would be broken if uncommented as-is.
• Leftover actor guard. if: github.actor != 'github-actions[bot]' was there to avoid an infinite loop from the commit-back step. With that step commented out, nothing pushes back to main, so the guard no longer serves a purpose — remove it or add a comment explaining why it stays.

Security

• Secrets handling looks good — QUAY_USERNAME / QUAY_ROBOT_TOKEN via secrets, no plaintext credentials.
• Least-privilege token. No permissions: block is set, so the job inherits the default GITHUB_TOKEN scopes. Since this job only pushes to an external registry, consider pinning permissions: contents: read to minimize blast radius.
• Actions are pinned to major tags (@v6, @v7, …) rather than commit SHAs. Tag pinning is the common convention and fine here; SHA-pinning third-party actions is the hardening option if supply-chain risk is a concern.

Performance

• No Docker layer / Gradle caching. Each push rebuilds the fat JAR from scratch inside the Docker build. Adding cache-from/cache-to (e.g. type=gha) to docker/build-push-action would meaningfully speed up repeat builds.

Minor / optional

• Concurrency. Rapid successive merges to main run overlapping builds. Because images are tagged by short SHA (type=sha,format=short, latest=false) they won't clobber each other, so this is benign — but a concurrency group would avoid wasted runs.
• Image tag discoverability for ArgoCD. With latest=false and only the short-SHA tag, ArgoCD needs a way to discover the newest tag (image updater / digest tracking). Flagging so the tagging strategy lines up with how ArgoCD picks up new images.

Tests

• No automated tests apply to a CI-workflow change. The realistic validation is a workflow_dispatch run confirming the image builds and pushes to Quay successfully — worth doing, since pull_request won't exercise this workflow.

Overall a reasonable first step toward the ArgoCD integration. The main things I'd address before merge are the duplicate workflow name and the dead commented block; caching and permissions are good follow-ups.

[alexandreferris]

should this commented code still be here?

[bbaarriiss]

Tbh, I just copied as is from QR App and made few changes to adapt.

Maybe @spoonman01 knows if we need to keep these or not.

[spoonman01]

You can delete that! We should also delete it from qr-app at some point

[bbaarriiss]

✅ done

[bbaarriiss]

ℹ️ PR ready also for QR App: https://github.com/wireapp/wire-qr-app/pull/116

Cc: @spoonman01 @alexandreferris