[waleedlatif1]

Summary

• migrate.yml takes workflow_dispatch with any environment and reads the database URLs from repo-level secrets, so dispatching it from a feature branch applies that branch's migrations to the chosen database, production included
• New first step fails the job unless github.ref is the environment's own branch: production from main, staging from staging, dev from dev. Runs before checkout and before any secret is read
• Fails instead of skipping: promote in ci.yml requires needs.migrate.result == 'success', and a skipped migrate must never look like one that ran
• Under workflow_call, github.ref is the caller's ref, so ci.yml's pushes (main -> production, staging -> staging, dev -> dev) pass unchanged
• scripts/migrations-workflow.test.ts grabbed the first run: | block in the file, which is now the guard; it anchors on the "Apply database schema changes" step instead
• Job-level concurrency block untouched

Durable fix (not applied here, needs repo admin)

The guard lives in the workflow file, so a dispatch from a branch that edits migrate.yml can still remove it. GitHub Environments close that gap because their branch policies are enforced by GitHub, not the workflow:

1. Pick environment names. production is the same environment as Vercel's Production (names are case-insensitive) and gets Vercel deployments on every main push; staging and dev hold old deployments from a previous host. None of them has protection rules today. Using dedicated names (migrate-production, migrate-staging, migrate-dev) avoids putting a required reviewer in front of Vercel's deployments
2. Create the three environments with deployment branch policy "Selected branches": main, staging, dev respectively. Add a required reviewer (and disallow self-review) on the production one
3. Re-enter the secrets as environment secrets: DATABASE_URL + MIGRATION_DATABASE_URL in production, STAGING_DATABASE_URL + STAGING_MIGRATION_DATABASE_URL in staging, DEV_DATABASE_URL in dev
4. Add environment: <name for ${{ inputs.environment }}> to the migrate job and drop the secrets: passthrough from both ci.yml callers (environment secrets are resolved in the called job)
5. Confirm one staging push migrates, then delete the repo-level copies of those secrets. docs.yml also reads repo-level DATABASE_URL, so either give it the production environment or keep a repo-level copy for it
6. Keep this guard as a second layer

Type of Change

• Bug fix

Testing

• Ran the guard script for each environment against its own branch (exit 0), a wrong branch, a tag ref, and an unknown environment (exit 1 with ::error::)
• actionlint on migrate.yml and ci.yml: clean for migrate.yml
• scripts/migrations-workflow.test.ts passes (5 tests)

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing (new tests pass the test-audit authoring gate)
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
docs	Ready	Preview	Oct 27, 2026 4:08am UTC

[cubic-dev-ai]

No issues found across 2 files

Confidence score: 5/5

• Automated review surfaced no issues in the provided summaries.
• No files require special attention.

_{Turn on auto-fix | Re-trigger cubic}

[greptile-apps]

Confidence Score: 5/5

[High impact] This PR appears safe to merge.

Summary

Adds a branch check before checkout and database steps in migrate.yml.

• Each database migration runs only from its environment's branch.

No actionable issues found. waleedlatif1 explicitly acknowledges that edited workflows can remove the guard; GitHub Environment protections are deferred to repository admins.

_{Reviews (1) · Last reviewed commit: "fix(ci): only migrate an environment fro..." · Reviewed by Greptile}