Revert "ci: move production deploy to declarative setup,

[atharvadeosthale]

Reverts #3061

[appwrite]

Appwrite Website

Project ID: 69d7efb00023389e8d27

Sites (1)

Site	Status	Logs	Preview	QR
website 69d7f2670014e24571ca	Failed	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

Git integration provides automatic deployments with optional PR comments

[greptile-apps]

Greptile Summary

This PR reverts #3061, which had migrated the production deployment from a direct Helm/Kubernetes approach to a declarative GitOps setup. Production goes back to deploying via kubectl/helm directly against the DigitalOcean cluster, while staging retains its declarative approach but with an updated target file (fra1.yaml instead of default.yaml).

• Production deploy is restored to a direct Helm upgrade flow with doctl kubeconfig, namespace/secret creation, and a matrix over regions — replacing the GitHub App + declarative repo commit approach.
• Action pin regression: Both files drop the SHA-pinned action references that ci: move production deploy to declarative setup, target default.yaml #3061 introduced, reverting to mutable version tags (@v4, @v3, @v6), which removes the supply-chain hardening.
• Dead env vars: STACK_FILE, REPOSITORY, and REGISTRY_USERNAME are declared in production.yml's env block but are never referenced by any step.

Confidence Score: 3/5

The revert restores a working deployment path but reintroduces unpinned third-party actions that run with access to sensitive production secrets.

The functional deployment logic looks correct — the Helm/kubectl approach is standard and the secret-injection steps use --dry-run=client | apply idempotently. The main concern is that all third-party action references are now unpinned mutable tags, including actions that run with access to DigitalOcean, GHCR, and Statsig credentials. This was an improvement that #3061 made and is now lost in the revert.

Both workflow files need SHA pins re-added to all third-party action references; production.yml also has three dead env vars worth cleaning up.

Security Review

• Supply chain / unpinned actions (.github/workflows/production.yml, .github/workflows/staging.yml): Both files drop SHA-pinned action references in favor of mutable version tags. Steps running with access to DIGITALOCEAN_ACCESS_TOKEN, GHCR_TOKEN, STATSIG_SERVER_SECRET, and other deployment secrets are now exposed to tag-hijacking risk on third-party actions (docker/login-action, docker/build-push-action, azure/setup-kubectl, azure/setup-helm, digitalocean/action-doctl).

Important Files Changed

Filename	Overview
.github/workflows/production.yml	Reverts declarative GitOps deploy to a direct Helm/Kubernetes deploy; drops SHA-pinned action references in favor of mutable version tags and leaves three unused env vars.
.github/workflows/staging.yml	Keeps declarative GitOps approach for staging but drops SHA-pinned action references and changes the target file from default.yaml to fra1.yaml; job-level concurrency group removed (workflow-level concurrency still protects).

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

[greptile-apps]

Unpinned action references expose supply chain risk

This revert drops the SHA-pinned action references that PR #3061 introduced (e.g., actions/checkout@34e114876..., docker/build-push-action@10e90e36...) in favor of mutable version tags (@v4, @v3, @v6). Mutable tags can be silently redirected by a compromised or hijacked upstream account, meaning the next deployment run could execute attacker-controlled code with access to all the secrets passed in this workflow (DIGITALOCEAN_ACCESS_TOKEN, GHCR_TOKEN, STATSIG_SERVER_SECRET, etc.). The same regression affects every unpinned action in staging.yml.

[greptile-apps]

Three unused env vars left in the workflow

STACK_FILE, REPOSITORY, and REGISTRY_USERNAME are declared in env but are never referenced by any step in the workflow. These appear to be leftovers from an older docker-compose-style deployment approach and can be safely removed to keep the workflow clean.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!