feat: Add Staging push to Quay.io

[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?

Solutions

Add staging.yml file

[claude]

PR Review: feat: Add Staging push to Quay.io

Thanks for adding the staging deploy workflow! It's clean and easy to follow. A few observations below, mostly around security hardening and small refinements.

Potential bugs / correctness

• `name: Build` collides with `pull-request.yml`. Both workflows declare `name: Build`, which makes them ambiguous in the Actions UI and in branch protection / status checks. Suggest renaming this one to something like `Staging` or `Deploy to Quay (staging)`. The job is `deploy-staging`, so a workflow name of `Build` is also a bit misleading.
• No `context:` is pinned for the build. Without an explicit `context:`, `docker/build-push-action` uses the Git context (re-clones the ref) rather than the files produced by the `Checkout` step. It works here, but if you ever rely on files modified during the job it will silently ignore them. Consider adding `context: .` to use the checkout.

Security

• Add an explicit least-privilege `permissions` block. This job only needs to read the repo and pushes to an external registry via secrets, so add at the top:
  ```yaml
  permissions:
  contents: read
  ```
  This avoids the repo/org default `GITHUB_TOKEN` scopes leaking into a job that handles registry credentials.
• Pin third-party actions to commit SHAs. Since this workflow has access to `QUAY_ROBOT_TOKEN` and pushes images, the `docker/*` actions are part of your supply chain. Pinning to a full commit SHA (with the version in a comment) protects against a compromised/retagged release, e.g. `uses: docker/build-push-action@ # v7`.

Reliability / performance

• No `concurrency` guard. Rapid merges to `main` can trigger overlapping runs that push images out of order. Consider:
  ```yaml
  concurrency:
  group: staging-deploy
  cancel-in-progress: false
  ```
• Consider build-layer caching to speed up repeated builds: add `cache-from: type=gha` / `cache-to: type=gha,mode=max` to the build-push step.

Tagging strategy

• Images are tagged only with `type=sha,format=short` and `latest=false`. For a staging registry, a moving tag (e.g. `type=raw,value=staging`) is often useful so the staging environment can always pull a stable reference rather than chasing each SHA. Depends on how your deployment consumes the image — just flagging it.

Minor

• The `if: github.actor != 'github-actions[bot]'` guard is a reasonable loop-breaker. Note that pushes from other bots/apps won't be covered; fine for now given the `push: main` trigger.

Tests

• N/A for a CI workflow change. The `workflow_dispatch` trigger (already present) is a good way to validate this on a branch before relying on the `main` push trigger.

Overall a clean, focused change — the main asks are the `permissions` block and the workflow-name collision.