Record the Preview deployment against the pull request head

[claude]

Requested by Aleksei A Leonov · Slack thread

Before: the merge gate on main is branch protection's "require deployments to succeed before merging", naming the Preview environment — it is not a status check. GitHub looks for a successful, active Preview deployment recorded against the pull request head commit. Until #681, environment: Preview sat on the build_and_preview job of a pull_request workflow, so every run recorded exactly that. #681 moved environment: Preview onto the deploy_preview job of a workflow_run workflow, where the run's SHA is main — so GitHub now records the deployment against main and the pull request head gets none. #680 is the evidence: GET /deployments?sha=96b422be returns zero deployments, the PR reads "All checks have passed — 2 successful checks" and "Merging is blocked — Missing successful active Preview deployment", while the deploy run created Preview deployment 6538016708 on ref: main, sha: 9083f0a9.

After: the privileged deploy job creates the Preview deployment itself against github.event.workflow_run.head_sha and completes it on every path, so each pull request gets the successful, active Preview deployment on its own head commit that branch protection is looking for — for fork and Dependabot pull requests too, which is what #681 set out to fix.

How: deployments: write is added to the workflow's permissions. A new step opens the deployment next to the existing Deploy Preview check run, before anything can fail, with auto_merge: false and required_contexts: [] (without the latter GitHub queues the request instead of creating a deployment) and with transient_environment/production_environment both false, matching the shape of the deployments the old workflow produced. A final always() step — mirroring the check run's single close site — sets success with the preview URL as environment_url, or failure when the deploy or the upstream build failed, so the deployment can never be left in_progress. Both statuses pass auto_inactive: false, which stops one pull request's preview from flipping every other pull request's Preview deployment to inactive; that is the second half of this problem, and it is why PR #644 still reads blocked today with both of its checks green — its head deployment was marked inactive back on 2026-03-08. The Deploy Preview check run is kept as-is, since branch protection cannot be read from inside a workflow and it may be required too; the comments now say plainly which of the two is the actual gate.

Note: this pull request will itself be blocked for exactly the same reason and needs a bypass merge. workflow_run workflows only ever run from the copy on the default branch, so the fix cannot produce a Preview deployment for its own head — it only takes effect once it is on main.

One caveat worth stating: the job keeps its job-level environment: Preview, because the Firebase service account secret may be scoped to that environment and dropping it could silently break secret access. GitHub therefore still records its own Preview deployment against main when the job ends. Our pull-request-head deployment is completed in the last step of the job so that it lands first; no Preview deployment in this repository has been auto-deactivated since 2026-08-04 (six successful deployments are simultaneously active), so this should not matter, but the ordering is load-bearing and unverified.

🤖 Generated with Claude Code

https://claude.ai/code/session_01NPMyesYBAqXnBx531rhVbY

---

Generated by Claude Code

[github-actions]

Firebase preview

Preview URL: https://storj-dev--pr-682-ccp1zipp.web.app

Expires: Sat, 26 Sep 2026 06:51:08 GMT