[andygrove]

Which issue does this PR close?

Closes #7475.

Rationale for this change

GitHub blocks the pull_request_target trigger by default on public repositories from December 2, 2026, with brownouts before then, and ASF infra is disabling it for ASF repositories. label_prs.yml runs on that trigger, so pull requests would stop getting their type and path labels. Upstream tracking issue: apache/datafusion#26406.

What changes are included in this PR?

The labeler is split into two workflows:

• label_prs_trigger.yml (new) runs on pull_request for opened, synchronize and reopened, the same events as before. It has permissions: {} and does nothing. It exists only so its completion can start the labeler.
• label_prs.yml now runs on workflow_run when the trigger workflow completes. workflow_run always runs the default branch's copy of the file with the repository token, so it can write labels on fork pull requests. It:
  • finds the open pull request whose head repository, branch and commit match the triggering run. Nothing produced by the PR's run is read, so there is no artifact to trust. If the head has moved on, the run for the newer push labels the PR instead.
  • applies the type label from the title with the existing dev/ci/pr-type-label.mjs, read from the default branch checkout. Dependabot PRs are still skipped.
  • applies the path labels with actions/labeler@v7, passing the PR through its pr-number input.
  • keeps the per-PR concurrency group with cancellation, now keyed on the head repository and branch because workflow_run doesn't carry the PR number. It also adds a repository guard so the workflow doesn't run in forks.

The standalone workflow table in .github/workflows/README.md is updated to match.

Behavior changes:

• PRs targeting a release branch now get type and path rules from main instead of from their base branch.
• Under pull_request, a first-time contributor's trigger run may wait for maintainer approval, depending on the repository's Actions settings. Their PR may not be labelled until a maintainer approves the run.

branch-1.2 still runs label_prs.yml on pull_request_target. After this merges, it needs a backport that adds label_prs_trigger.yml there and removes its label_prs.yml. A pull_request run uses the workflow files from the PR's base branch, but the labeler on main picks up the trigger run from any branch.

How are these changes tested?

• python3 dev/ci/check-ci-config.py and actionlint pass on both workflows.
• node --test dev/ci/pr-type-label.test.mjs still passes. The title logic is unchanged.
• I checked the PR lookup with the same REST call on an open fork PR: GET /pulls?state=open&head=<owner>:<branch> returns docs: apply the style guide's "native" rules to timezones.md #7477 with the expected head SHA and repository.
• workflow_run only fires from the default branch's copy of a workflow, so this can't be tested end to end until it merges. After merge, opening or pushing to any PR should start Label pull requests trigger and then Label pull requests, and the PR should get its labels.

[manuzhang]

LGTM. Do we need back-port to branch-1.1 as well?

[comphead]

Thanks @andygrove. The privileged job reads nothing the PR's run produced, and only an API-derived PR number reaches with:, so the security model looks right to me. On @manuzhang's question: upstream/branch-1.1 also still has label_prs.yml on pull_request_target, so it needs the same backport as branch-1.2.

[comphead]

Nothing checks that this entry stays equal to the name: of label_prs_trigger.yml. If either is renamed, labeling stops without a failing check. dev/ci/check-ci-config.py already guards the same pairing for the fork bridge (BRIDGE_WORKFLOW against the name of ci.yml, plus the repository guard). Could it cover this pair too?

[comphead]

The events reference says pull_request workflows do not run while the PR has a merge conflict, and pull_request_target ones do. A PR opened with a conflict now gets no labels until a push after the conflict is resolved. Could this go in the list of behavior changes, or be covered by a schedule sweep like the one in fork_ci_status.yml?