andygrove opened a new pull request, #7482:
URL: https://github.com/apache/datafusion-comet/pull/7482
## 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 #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.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
