## Problem
API type changes still use the api-deploy-required label and an
informational comment even though production verification has proven
reliable enough to block merges.
## Fix
Remove the obsolete API label path, scope the remaining labeler workflow
to docs changes, and update the API-types guidance. Master branch
protection now requires the app-bound verify-production-api-types check.
## How to test
- Confirm the labeler workflow only runs for changes under apps/docs.
- Confirm API type changes no longer receive the api-deploy-required
label or comment.
- Confirm master branch protection lists verify-production-api-types as
a required GitHub Actions check.
- Expected result: production API type verification blocks mismatched
generated types while unrelated pull requests receive a successful
skipped verification job.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Chores**
* API type verification is now a required merge check; guidance to run
it before review and treat failures as production drift remains.
* Removed the API deployment label rule and the automated comment
triggered when that label was applied.
* The pull request labeling workflow now runs only for changes affecting
the documentation app.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## I have read the
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
file.
YES
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Chores**
* Updated GitHub workflow configuration for improved pull request
management and categorization.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## I have read the
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
file.
YES
## What kind of change does this PR introduce?
CI / tooling — GitHub Actions workflow update.
## What is the current behavior?
PRs that modify `packages/api-types/types/**` can be merged before the
corresponding API has shipped to production, breaking the Studio
frontend when it calls endpoints that do not exist yet. The
`api-deploy-required` label is enforced only by convention and code
review, which is easy to miss.
## What is the new behavior?
- `.github/labeler.yml`: auto-applies `api-deploy-required` to any PR
that touches `packages/api-types/types/**`.
- `.github/workflows/label_prs.yml`: drops the `apps/docs/**/*` path
filter so the labeler runs on all PRs, and posts a one-time comment when
`api-deploy-required` is newly added (uses the labeler's `new-labels`
output so re-pushes do not re-comment).
- `.github/workflows/validate-pr.yml`: adds a step that fails the
`Validate pull request` check while the `api-deploy-required` label is
present, mirroring the existing `do-not-merge` pattern. The author
removes the label after confirming the API is live to unblock merge.
Reviewer: please confirm `Validate pull request` is configured as a
required check on `master` in branch protection — that step is what
enforces the block.
## Additional context
Resolves FE-3479
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Chores**
* Enhanced pull request automation with improved labeling rules for
API-related changes.
* Added validation that blocks pull request merging until API deployment
is confirmed for changes affecting API types.
<!-- review_stack_entry_start -->
[](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/46482?utm_source=github_walkthrough&utm_medium=github&utm_campaign=change_stack)
<!-- review_stack_entry_end -->
<!-- end of auto-generated comment: release notes by coderabbit.ai -->