ci: move production deploy to declarative setup

[levivannoort]

Reverts #3063

[appwrite]

Appwrite Website

Project ID: 69d7efb00023389e8d27

Sites (1)

Site	Status	Logs	Preview	QR
website 69d7f2670014e24571ca	Building	View Logs	Preview URL

Website (appwrite/website)

Project ID: 684969cb000a2f6c0a02

Sites (1)

Site	Status	Logs	Preview	QR
website 68496a17000f03d62013	Processing	View Logs	Preview URL

---

Tip

Function scopes give you fine-grained control over API permissions

[greptile-apps]

Greptile Summary

This PR migrates the production deployment workflow from an imperative Kubernetes/Helm approach to the same declarative GitOps pattern already used by staging, reverting #3063. It also pins all third-party action references to full commit SHAs and renames the staging target file from fra1.yaml to default.yaml.

• The production deploy job now checks out the assets-applications repo via a GitHub App token, updates production/website/default.yaml with yq, and commits/pushes — identical in structure to the staging job.
• All actions/checkout, docker/login-action, docker/build-push-action, and actions/create-github-app-token references are pinned to exact SHAs with version comments.
• Both the staging and production deploy jobs now share the concurrency group declarative-deploy-website, which will serialize them against each other even though they write to different paths in the target repository.

Confidence Score: 3/5

The core GitOps migration is straightforward and mirrors the working staging pattern, but the shared concurrency group between staging and production could silently delay production releases behind unrelated staging runs.

The production deploy job now shares a concurrency group with the staging deploy job. Since staging triggers on every push to main, any active staging deployment will queue a concurrent production release with no cancellation allowed. The two workflows write to different files so there is no technical conflict — this is a coordination mistake that could cause unexpected delays for time-sensitive production releases.

.github/workflows/production.yml and .github/workflows/staging.yml both need the concurrency group name corrected.

Important Files Changed

Filename	Overview
.github/workflows/production.yml	Migrates production deploy from Kubernetes/Helm to a declarative GitOps approach (matches staging); pins all action SHAs; shares concurrency group with staging which can serialize unrelated deployments.
.github/workflows/staging.yml	Pins action SHAs, renames target file from fra1.yaml to default.yaml, and adds a concurrency group to the deploy job; same shared-group concern applies here.

_{Reviews (1): Last reviewed commit: "Revert "Revert "ci: move production depl..." | Re-trigger Greptile}

[greptile-apps]

Shared concurrency group with staging may queue production releases

Both production.yml (this file, line 57-59) and staging.yml (line 72-74) use the exact same concurrency group name declarative-deploy-website. Because GitHub Actions concurrency groups are scoped across workflows in the same repo, a staging deploy triggered by every push to main will block a production release (and vice versa) until it finishes. With cancel-in-progress: false the queuing is silent — a production release could be delayed waiting on an unrelated staging run. Since the two environments write to different paths (staging/website/default.yaml vs production/website/default.yaml) in the target repo, there is no actual git-conflict reason to serialise them. Consider suffixing the group name with the environment, e.g. declarative-deploy-website-${{ env.ENVIRONMENT }}.