ci: point deployment pipelines at default.yaml

[levivannoort]

Summary

Switches both the staging and production deployment workflows to update default.yaml instead of fra1.yaml in the appwrite-labs/assets-applications declarative repo. This moves production onto the same declarative setup staging already used, just region-agnostic.

Changes

• .github/workflows/staging.yml — staging/mcp/fra1.yaml → staging/mcp/default.yaml (yq update + git add)
• .github/workflows/production.yml — production/mcp/fra1.yaml → production/mcp/default.yaml (yq update + git add)

Note

The yq -i step edits the file in place, so default.yaml must already exist under staging/mcp/ and production/mcp/ in the assets repo, otherwise the deploy step will fail. Worth confirming before merge.

🤖 Generated with Claude Code

[greptile-apps]

Greptile Summary

This PR re-targets both the staging and production deployment workflows from fra1.yaml to default.yaml in the appwrite-labs/assets-applications declarative repo, and improves the deploy step with retry-with-rebase push logic and a job-level concurrency guard.

• production.yml: fra1.yaml → default.yaml; || github.sha fallback removed from TAG (empty on workflow_dispatch — already flagged in a prior thread); new concurrency: group: declarative-deploy on the deploy job.
• staging.yml: fra1.yaml → default.yaml; same concurrency: group: declarative-deploy on the deploy job — identical to production's, serializing the two pipelines at the repository level.
• Both workflows gain a retry loop (git pull --rebase up to 5 times) to handle concurrent pushes to the declarative repo.

Confidence Score: 4/5

The file rename and retry logic are safe, but the shared concurrency group between staging and production means a staging deploy actively blocks a production release deploy.

The core rename from fra1.yaml to default.yaml is straightforward and the retry-with-rebase loop is a solid improvement. The shared declarative-deploy concurrency group across both workflows is the key concern: a staging deploy running on every push to main can queue and hold a production deploy, which is an operational risk in hotfix scenarios.

.github/workflows/production.yml — the shared deploy concurrency group and the empty-TAG risk on manual triggers both live here.

Important Files Changed

Filename	Overview
.github/workflows/production.yml	Switches deploy target from fra1.yaml to default.yaml, removes the `
.github/workflows/staging.yml	Switches deploy target from fra1.yaml to default.yaml, adds the same declarative-deploy concurrency group on the deploy job (shared with production.yml), and adds the same retry-with-rebase push loop. TAG is github.sha here so no empty-tag risk.

_{Reviews (3): Last reviewed commit: "ci: serialize deploy jobs with a shared ..." | Re-trigger Greptile}

[greptile-apps]

Empty TAG on workflow_dispatch triggers

The || github.sha fallback was removed alongside the file rename, but this workflow still supports manual workflow_dispatch runs. When triggered that way, github.event.release.tag_name is empty, so TAG becomes an empty string. This causes the Docker build step to push an image tagged "", and the yq step to write an empty string into default.yaml's image.tag field — silently corrupting the declarative config in the assets repo. The original code handled this correctly; the fallback should be restored.

Suggested change

	TAG: ${{ github.event.release.tag_name }}
	TAG: ${{ github.event.release.tag_name || github.sha }}