codekongdev opened a new pull request, #2778:
URL: https://github.com/apache/datafusion-ballista/pull/2778
# Which issue does this PR close?
Closes #2773.
# 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. The Labeler workflow
(`.github/workflows/dev_pr.yml`) runs on that trigger, so pull requests would
stop getting their path labels. Upstream tracking issue:
apache/datafusion#26406.
# What changes are included in this PR?
The labeler is split into two workflows, following the lookup that
apache/datafusion#26683 and apache/datafusion-comet#7482 use:
- `dev_pr_trigger.yml` (new, `Labeler trigger`) runs on `pull_request` for
`opened`, `reopened` and `synchronize`. It has `permissions: {}` and does
nothing. It exists only so that its completion can start the labeler.
- `dev_pr.yml` (`Labeler`) now runs on `workflow_run` when the trigger
completes. `workflow_run` always runs the default branch's copy of the file,
with a token that can write labels on fork pull requests. The job:
- finds the open pull requests whose head repository, branch and commit
match the triggering run, with `actions/github-script`.
`workflow_run.pull_requests` is empty for fork pull requests, so it can't be
used. No artifact is read and nothing from the pull request is checked out or
run. A commit that is no longer a head matches nothing, because the run for the
newer push labels the pull request. If one branch has pull requests open
against several bases, all of them are labeled.
- passes the numbers to `actions/[email protected]` through its `pr-number`
input. The config file, `sync-labels: true` and the `macos-latest` runner stay
the same. With no checkout, the labeler reads
`.github/workflows/dev_pr/labeler.yml` through the API at the default branch's
commit.
- declares `permissions: {}` at the top level and `contents: read` and
`pull-requests: write` on the job.
- keeps the concurrency group with cancellation. It is now keyed on the
head repository and branch, because `workflow_run` doesn't carry the pull
request number.
I also removed the commented-out `actions-label-merge-conflict` step. It was
written for `pull_request_target` and wouldn't work as it is under
`workflow_run`.
Behavior changes:
- `edited` is no longer a trigger. The old labeling step already skipped it,
so it only started a job that did nothing. `reopened` is new.
- A first-time contributor's trigger run may wait for maintainer approval,
depending on the repository's Actions settings. Their pull request isn't
labeled until the run is approved.
- GitHub doesn't run `pull_request` workflows while a pull request has merge
conflicts. A conflicting pull request is labeled once the conflict is resolved.
- A pull request runs its own copy of `dev_pr_trigger.yml`, so it can change
or delete it. The only effect is that the pull request isn't labeled.
`dev_pr.yml` reads nothing from the run apart from its head repository, branch
and commit.
- `branch-53`, `branch-54` and `branch-55` still have the
`pull_request_target` version of `dev_pr.yml`. Backport pull requests won't be
labeled once the trigger is blocked unless `dev_pr_trigger.yml` is backported
too. The labeler on `main` picks up trigger runs from any branch. I left that
for a follow-up.
# Are there any user-facing changes?
No. This only changes CI.
# How are these changes tested?
`workflow_run` only fires from the default branch's copy of a workflow, so
this can't run end to end before it merges. What I checked:
- Both files parse as YAML. `workflows: [Labeler trigger]` matches the
trigger's `name`, and no other workflow uses that name. `actions/github-script`
is owned by `actions`, which the ASF allowlist check trusts.
- I extracted the `github-script` body from `dev_pr.yml` and ran it with
Node against the real REST API, using the payloads of real `pull_request` runs
in this repository:
- fork pull requests #2774
(`NoahKusaba:perf/sort-shuffle-split-on-arrival-v2`) and #2776
(`milenkovicm:fix_2768`), whose runs have an empty `pull_requests`, resolve to
`2774` and `2776`
- same-repository pull request #2777 (dependabot) resolves to `2777`
- a head commit that no longer matches gives no output, and so does a
deleted fork (`head_repository: null`)
- with stubbed API data, two pull requests from one branch give both
numbers, one per line. A pull request from another repository whose branch and
commit match is ignored.
- I checked the `actions/labeler` v7.0.0 source. `pr-number` is read with
`getMultilineInput`, and a config file that isn't on disk is fetched through
the API at `github.context.sha`. Under `workflow_run` that is the latest commit
on the default branch.
After this merges, opening or pushing to a pull request should run `Labeler
trigger` and then `Labeler`, and the pull request should get its labels.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
--
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]
