feat: gate deployments from non-collaborators behind approval#5255
feat: gate deployments from non-collaborators behind approval#5255Flo4604 wants to merge 11 commits intofeat/github-deployment-statusfrom
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Warning This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
This stack of pull requests is managed by Graphite. Learn more about stacking. |
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
Add deployment protection that checks if the push sender is a repo collaborator before triggering a deployment. Non-collaborators get their deployment created in awaiting_approval status with a PR comment posted linking to the approval page. - Add awaiting_approval status to deployments enum - Add deployment_protection boolean to projects table - Add deployment_approvals table for audit trail - Add sender_login to HandlePushRequest proto - Add IsCollaborator, FindPullRequestForBranch, CreateIssueComment to GitHub client (with SWR cache for collaborator checks) - Inject GitHub client into webhook service for collaborator checks - Bot accounts ([bot] suffix) are auto-approved - Fails open if collaborator check errors
Add Drizzle ORM schema mirroring Go schema.sql changes: - awaiting_approval status and github_deployment_id on deployments - deployment_protection boolean on projects - deployment_approvals table
- Create GitHub Deployment with pending status when approval is required - Add dashboardURL to webhook service for PR comment approve links - Add FORCE_DEPLOYMENT_APPROVAL env var for local testing - Set FORCE_DEPLOYMENT_APPROVAL=true in dev k8s manifest
… on rejection - Add 'rejected' to deployments status enum in schema, models, proto, and drizzle - Add ApproveDeployment and RejectDeployment ConnectRPC handlers - RejectDeployment sets status to 'rejected' (not 'failed') and reports failure to GitHub - ApproveDeployment triggers deploy workflow after status/approval update - Add FindAppBuildSettingByAppEnv query for approve handler - Wire Noop GitHub client into API deployment service - Handle new statuses in exhaustive switch (get_deployment.go)
Remove GitHub client from API deployment service — the API doesn't have GitHub App credentials. Instead, reject handler fires a Restate call to the worker's new UpdateGitHubDeploymentStatus handler which owns the GitHub client and performs the actual API call.
- Add UpdateIssueComment and FindBotComment to GitHub client interface - Post/update a single PR comment (find-by-marker) showing deployment status table with environment, status, preview URL, and timestamp - Update comment at each deploy phase: building, deploying, ready, failed - Approval comment also uses find-and-update to avoid duplicates on re-push
Remove the PR comment for approval-gated deployments. The GitHub Deployment pending status already shows in the PR sidebar — no separate comment needed. Removes unused fmt import.
- Remove FindPullRequestForBranch, CreateIssueComment, UpdateIssueComment, FindBotComment from GitHub client interface and implementations - Delete github_comment.go (PR comment reporter) - Remove all updatePRComment calls from deploy_handler.go - Add log_url to pending GitHub deployment status in approval flow so clicking the check on GitHub links to the dashboard approval page - Fix exhaustruct lint for seed/harness test files
Show a red failed check on the PR instead of a yellow pending dot when a deployment requires authorization. Clicking the check links to the dashboard approval page.
Remove awaiting_approval/rejected status from deployments table and drop deployment_approvals table. External contributor pushes no longer create a deployment record — instead handle_push creates a GitHub Deployment check with failure status linking to an authorize page. Replace ApproveDeployment/RejectDeployment RPCs with a single AuthorizeDeployment RPC that takes project_id + branch, fetches HEAD from GitHub, re-derives deploy contexts, and creates deployments.
GitHub Deployments only appear in the PR Environments section. This adds Check Runs via the Checks API so blocked deployments show a prominent yellow "action_required" badge in the PR checks list. On authorization, the check run is updated to green success.
36216f3 to
66dad62
Compare
162f137 to
8401e8a
Compare

What does this PR do?
Implements deployment protection for external contributors by adding authorization controls for GitHub webhook-triggered deployments. When deployment protection is enabled on a project, pushes from non-collaborators will require manual approval before deployment workflows are triggered.
Key Changes:
AuthorizeDeploymentRPC endpoint that fetches the current HEAD commit from GitHub and creates deployment records for approved external contributionsdeployment_protectionfield to projects table andgithub_deployment_idfield to deployments tableFORCE_DEPLOYMENT_APPROVALflag for testing authorization flowsThe system creates GitHub Deployment checks with failure status for blocked deployments, providing clear feedback to contributors with links to the authorization page.
Type of change
How should this be tested?
FORCE_DEPLOYMENT_APPROVAL=trueenvironment variableChecklist
Required
pnpm buildpnpm fmtmake fmton/godirectoryconsole.logsgit pull origin mainAppreciated