Help with Branch Rule Protection - Deployment Required

[joaosarmentoptc]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Workflow Deployment

Discussion Details

I am facing a strange behavior on a specific repository.

I have a workflow to build and deploy specific branches, and a branch protection rule that requires a successful deployment to "qa" environment before merging.

This is working fine for every repository that I have, except for one. I am not sure what is the issue here.
As you can see it's identifying an active success deployment on qa, however merging is blocked because there's no active deployment on qa... wth?

[OscarRondon-dev]

Ran into something similar — the UI showing a successful deployment while branch protection says "no active deployment" usually comes down to a mismatch in what "active" means for the rule.

A few things to check on the problem repo specifically:

Environment name must match exactly. The branch rule references an environment called qa. If your workflow deploys to QA or qa-env, protection won't count it. Case-sensitive.

Which deployment counts. Branch rules look for a deployment on the head commit of the PR. If the successful deployment you see is on an older commit or a different branch, the merge will still be blocked.

Environment protection rules. Go to Settings → Environments → qa. Check if "Required reviewers" or "Wait timer" left a deployment in waiting or inactive state even though the job succeeded.

Compare with a working repo. Diff these between working and broken repos:

• Settings → Branches → rule → "Require deployments to succeed"
• Settings → Environments → qa → deployment branches allowed
• The environment: key in your workflow YAML

The screenshot showing success in the Environments panel but block on merge often means the deployment exists but isn't tied to the commit the PR is trying to merge. Re-run the workflow on the PR head commit and see if the merge button unlocks.

If you can share whether the deployment runs on pull_request vs push to the feature branch, that usually explains why one repo works and another doesn't.

[joaosarmentoptc]

Hi @OscarRondon-dev,

I just diffed between working repo and this one. This behavior is just on this one.
All the branch protection rules are exactly the same.
Theres no case sensitive scenario here as well, since github list down all the possible environments, and right now theres just this one, there is no extra space or case sentitive letters, just plain lower case "qa"

The yaml also matches plain lowercase "qa", in fact, the environment is created automatically when the deployment first run against a specific environment.

This has been consistent in all my repos (11 different repos have consistent behavior, except for this one). Which makes me believe there is something broken on gh side.

Edit: I tried deleting the environment and created again, still no luck.
Edit2:

Created another environment, and got the same behavior..

[OscarRondon-dev]

Looking at your screenshot again, the deployment GitHub is showing is on commit 97f0bdc8 from last week. The branch rule doesn't just need "a successful qa deployment on this branch" — it needs one on the PR's current head commit.

Can you check whether the PR head SHA is still 97f0bdc8? If it's moved forward since that deploy, the green "successfully deployed" banner can stay while merge stays blocked. That's the most common cause of exactly this UI contradiction.

Quick test: re-run the deploy workflow against the current PR head (push an empty commit or use workflow_dispatch if you have it) and see if merge unlocks.

If the head SHA is already 97f0bdc8 and it's still blocked after a fresh deploy on that exact commit, then yeah — with identical rules across 11 repos that starts looking like a backend issue on this specific repo. I'd grab the deployment URL/ID from the Environments page and open a GitHub Support ticket with both SHAs side by side.Thanks for the follow-up — ruling out name/config mismatch helps narrow it down.

Looking at your screenshot again, the deployment GitHub is showing is on commit 97f0bdc8 from last week. The branch rule doesn't just need "a successful qa deployment on this branch" — it needs one on the PR's current head commit.

Can you check whether the PR head SHA is still 97f0bdc8? If it's moved forward since that deploy, the green "successfully deployed" banner can stay while merge stays blocked. That's the most common cause of exactly this UI contradiction.

Quick test: re-run the deploy workflow against the current PR head (push an empty commit or use workflow_dispatch if you have it) and see if merge unlocks.

If the head SHA is already 97f0bdc8 and it's still blocked after a fresh deploy on that exact commit, then yeah — with identical rules across 11 repos that starts looking like a backend issue on this specific repo. I'd grab the deployment URL/ID from the Environments page and open a GitHub Support ticket with both SHAs side by side.

[joaosarmentoptc]

I reran the deployment, no changes. you can see that on my latest screenshot in my previous reply
and yes, I am aware that if there are most recent commits, the deployment validation gets invalidated. The 97f0bdc8 is the latest commit.
This issue is consistent on all branches / PR's across this repository. Not just this one.
Looks like this is some kind of github bug in this specific repository.

[OscarRondon-dev]

Fair point if the head is already 97f0bdc8, you redeployed, and it happens on every PR in this repo with identical config elsewhere, that really does smell like a backend/cache issue on GitHub's side for this specific repository, not a config mistake. I've been trying to reproduce the failure to explore the possibilities, but I haven't managed to do so 😅

[joaosarmentoptc]

By any chance this is monitored by github support? Or is there a way to report this to them so they could look into it?

[ali-dev-uae]

When GitHub branch protection rules require a successful deployment (e.g., to environment 'qa') before merging, the deployment check evaluates specific criteria:

1. Deployment API State vs Workflow Status:
   GitHub's branch rule engine verifies GitHub Deployment API status payloads (state: success), NOT just the GitHub Actions job run result. If your workflow uses environment: qa without explicitly issuing a deployment status or if deployment webhooks fail to update the API deployment object on that commit, the merge check remains pending.

2. Deployment Target Commit Alignment:
   The successful deployment must be associated with the EXACT head commit SHA of the Pull Request branch (github.event.pull_request.head.sha). If the workflow triggered on push to a topic branch, confirm that the deployment payload targets the PR head SHA rather than a merge commit SHA generated by pull_request.

3. Re-evaluating the Environment Deployment:
   You can trigger a fresh GitHub deployment record by triggering your deployment workflow directly on the current head commit or by pushing an updated commit.

If you continue to experience this issue across a single specific repository while 10+ identical repos function, navigate to your Repository Settings -> Actions -> General and verify Workflow Permissions (Read & Write permissions and Allow GitHub Actions to create and approve pull requests). Occasionally, restricted GITHUB_TOKEN permissions silently block the GitHub deployment status API creation while allowing job execution to finish as green.

[felipebridge]

To answer the actual question at the end here: no, Community Discussions aren't a monitored support queue. Replies here (mine included) are just other users, not GitHub staff, unless you literally see a "Staff" badge on someone's name. So this thread on its own isn't going to get an engineer poking at your repo's backend state.

What actually works is opening a ticket at support.github.com and picking Actions (or Repositories) as the topic. The thing that gets these escalated past the generic first-reply instead of bouncing back with "please check your config" is giving them something they can't explain away: the PR URL, the deployment ID/URL from the Environments page for the qa deployment showing success, both SHAs (PR head vs whatever the deployment API says it deployed), and the one line that matters most — identical branch protection config works on 11 other repos and fails on every single PR in this one. That's not a "did you typo the environment name" ticket, that's a "something is broken in the deployment-status backend for this repo specifically" ticket, and it reads that way to whoever triages it.

If you're on a paid plan (Team/Enterprise) it's also worth checking under Settings → Billing which support tier you're on before filing, since that changes the queue and the SLA you get.

[joaosarmentoptc]

Thank you very much for this answer. I'll do as suggested.