comphead opened a new pull request, #26683: URL: https://github.com/apache/datafusion/pull/26683
## Which issue does this PR close? - Related to the ASF infra policy: "From November 2026, the pull_request_target trigger is disabled for ASF repositories" (https://infra.apache.org/github-actions-policy.html). See SPARK-60440 for the same migration in Spark Connect Swift. ## Rationale for this change Three workflows use `pull_request_target`: `labeler.yml`, `fork_ci_status.yml` and `release_version_labeler.yaml`. ASF infra disables the trigger from November 2026. GitHub also adds a default policy that blocks it on public repositories, enforced from 2026-12-02. Without this change, PRs stop getting labels, the `Rust (fork)` check and the release version label. ## What changes are included in this PR? - Add `pull_request_signal.yml`, an unprivileged `pull_request` workflow with `permissions: {}` and one `echo` step. - `labeler.yml` and `fork_ci_status.yml` run on `workflow_run` of that workflow with `types: [requested]`. GitHub runs them from the default branch, so they never run PR code. `requested` is sent at once, even for a first-time contributor whose run waits for approval. - `workflow_run.pull_requests` is empty for fork PRs. Both workflows find the PR from `head_repository`, `head_branch` and `head_sha` with `pulls.list`, and skip a commit that is no longer the PR head. `labeler.yml` passes the number to `actions/labeler` as `pr-number`. - Concurrency groups use the `workflow_run` head repository and branch, since `github.head_ref` and the PR number are not set. - `release_version_labeler.yaml` runs on `push` to `main` and labels the merged PR found with `listPullRequestsAssociatedWithCommit`. - `test_fork_ci_status.cjs` now drives the notification with a `workflow_run` payload and covers the stale commit case. ## What is the testing strategy for this PR? - `node --test ci/scripts/test_fork_ci_status.cjs` passes (25 tests). - `actionlint` reports nothing on the four workflows. - The `workflow_run` flow only takes effect after the merge to `main`, because GitHub runs these workflows from the default branch. It is not tested end to end. Things to check after the merge: that `actions/labeler` reads `labeler-config.yml` from the default branch, that the push-time PR lookup finds merge queue commits without a race on `merged_at`, and that a PR from a fork gets labels and the `Rust (fork)` check. ## Are there any user-facing changes? No. A PR with merge conflicts does not start `pull_request` workflows, so it is labeled and gets the `Rust (fork)` check once the conflicts are resolved. The `edited` label trigger was dropped, since the old workflow skipped that action already. -- 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]
