feat: switch to declarative staging-workflow with mirror to dockerhub

[levivannoort]

What does this PR do?

(Provide a description of what this PR does.)

Test Plan

(Write your test plan here. If you changed any code, please provide us with clear instructions on how you verified your changes work.)

Related PRs and Issues

(If this PR is related to any other PR or resolves any issue or related to any issue link all related PR and issues here.)

Have you read the Contributing Guidelines on issues?

(Write your answer here.)

[appwrite]

Appwrite Website

Project ID: 69d7efb00023389e8d27

Sites (1)

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

GraphQL API works alongside REST and WebSocket protocols

[greptile-apps]

Greptile Summary

This PR replaces the imperative Helm/Kubernetes deployment with a declarative GitOps approach: after building and pushing the Docker image to both GHCR and Docker Hub, the workflow checks out a separate assets-applications repo via a GitHub App token and commits the updated image tag there.

• The build job now pushes to both GHCR and Docker Hub simultaneously, using ${{ github.sha }} as the tag.
• The deploy job drops all kubectl/doctl steps and instead uses yq to patch a fra1.yaml file in the declarative repo, then commits and pushes the change.
• A workflow-level concurrency group (cancel-in-progress: false) serialises runs so concurrent pushes don't race on the YAML commit.

Confidence Score: 3/5

The workflow logic is sound but the mikefarah/yq@v4 action runs in the job that holds a GitHub App token with write access to the declarative deployment repo; a floating tag on a third-party action in that position warrants a pin before merging.

The refactor correctly implements the GitOps pattern and the concurrency guard prevents race conditions on the YAML commit. The main concern is mikefarah/yq@v4 — a floating major-version tag on a third-party action that executes inside the privileged deploy job where the GitHub App private key is in scope. If that tag is ever redirected, the action could exfiltrate secrets or push malicious content to the declarative repo.

.github/workflows/staging.yml — specifically the deploy job and its use of mikefarah/yq@v4.

Important Files Changed

Filename	Overview
.github/workflows/staging.yml	Refactors staging deployment from imperative Helm/kubectl to a declarative GitOps pattern: builds the image, mirrors it to Docker Hub, then updates a YAML file in a separate repo via a GitHub App token. One third-party action (mikefarah/yq@v4) runs in the privileged deploy job with a floating tag, creating a supply-chain risk. A redundant env var (DOCKERHUB_IMAGE_NAME) duplicates IMAGE_NAME.

_{Reviews (1): Last reviewed commit: "feat: switch to declarative staging-work..." | Re-trigger Greptile}

[greptile-apps]

Unpinned third-party action with privileged repo access

mikefarah/yq@v4 is resolved at runtime to whatever commit the v4 tag currently points to. This step runs in the deploy job, which already holds the GitHub App token capable of pushing to assets-applications. If the v4 tag were ever moved to a malicious commit (compromised maintainer account, tag hijack, etc.), it would run with that token in scope. Pin the action to a specific commit SHA to eliminate this vector — e.g. mikefarah/yq@<full-sha>.

[greptile-apps]

IMAGE_NAME and DOCKERHUB_IMAGE_NAME are both set to appwrite/website, making one of them redundant. The tag lines on lines 50–51 only differ in the registry prefix, so a single IMAGE_NAME variable is sufficient for both.

Suggested change

	IMAGE_NAME: appwrite/website
	DOCKERHUB_IMAGE_NAME: appwrite/website
	IMAGE_NAME: appwrite/website

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!