You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Bug: CI Label pull request job fails on all fork PRs since #14411 #14438
The Label pull request / add_label job fails on every pull request opened from a fork. The run is rejected at the environment gate before any step executes, with:
Branch "main" is not allowed to deploy to github-app-auth due to environment
protection rules. The deployment was rejected or didn't satisfy other protection rules.
The job fails in 1-2 seconds.
label-pr.yml runs on pull_request_target and declares environment: github-app-auth. On that trigger the workflow is evaluated in the context of the base branch (main), which appears not to satisfy the environment's protection rules. label-issues.yml and devflow-pr-review.yml declare the same environment.
Timing points to #14411 ("Replace workflow PAT usage with GitHub App authentication", merged Sep 11) as the origin — #14150 is a months-old PR whose add_label runs previously passed and now fail, with no change to its diff.
To Reproduce
Open a pull request from a fork against main.
Open the Checks tab and select Label pull request / add_label.
See the run fail in 1-2 seconds with the environment protection rule error above.
Affected (fork PRs): #14437, #14434, #14150.
Not affected (in-repo branch): #14393 (Dependabot) — no deployment failure, and the dependencies and python labels were applied normally.
Expected behavior
add_label runs to completion on fork PRs and applies the appropriate area labels, it did before #14411.
Screenshots
N/A
Platform
Language: N/A (GitHub Actions workflow, not SDK code)
Side effect: incoming community PRs are not being auto-labeled, which may be affecting triage and none of the three affected PRs above carry area labels.
changed the title [-]Bug: CI Label pull request job fails on all fork PRs since #14411[/-][+]Python: Bug: CI Label pull request job fails on all fork PRs since #14411[/+]on Sep 13, 2026
changed the title [-]Python: Bug: CI Label pull request job fails on all fork PRs since #14411[/-][+]Bug: CI Label pull request job fails on all fork PRs since #14411[/+]on Sep 13, 2026
I can take a look at the fork-PR labeling regression. I will first verify the workflow context and prepare the smallest change that restores labeling without widening permissions, then add or update workflow-level validation if the repository has a suitable test path.
PR #14457 is a minimal attempt to restore fork-PR labeling with the built-in pull-request token and a workflow-level test. The automated review correctly raised that removing the protected environment may also remove required app credentials. Before changing it further, could a maintainer confirm whether the intended design is a fork-safe github.token path, a two-job split, or retention of the app-token path for trusted runs, and assign the issue?
Activity
[-]Bug: CI Label pull request job fails on all fork PRs since #14411[/-][+]Python: Bug: CI Label pull request job fails on all fork PRs since #14411[/+][-]Python: Bug: CI Label pull request job fails on all fork PRs since #14411[/-][+]Bug: CI Label pull request job fails on all fork PRs since #14411[/+]lindicaphxag-tech commentedon Sep 18, 2026
I can take a look at the fork-PR labeling regression. I will first verify the workflow context and prepare the smallest change that restores labeling without widening permissions, then add or update workflow-level validation if the repository has a suitable test path.
lindicaphxag-tech commentedon Sep 19, 2026
PR #14457 is a minimal attempt to restore fork-PR labeling with the built-in pull-request token and a workflow-level test. The automated review correctly raised that removing the protected environment may also remove required app credentials. Before changing it further, could a maintainer confirm whether the intended design is a fork-safe
github.tokenpath, a two-job split, or retention of the app-token path for trusted runs, and assign the issue?