amaechler opened a new pull request, #20693: URL: https://github.com/apache/druid/pull/20693
### Description The ASF [GitHub Actions policy](https://infra.apache.org/github-actions-policy.html) forbids `pull_request_target` on workflows that expose `GITHUB_TOKEN`, and disables the trigger for ASF repositories from November 2026. `labeler.yml` and `pr-merged.yml` use it, so both would stop running next month. #### Labeler: signal workflow plus `workflow_run` This follows the replacement pattern from the ASF policy. - The new `labeler-signal.yml` ("Pull Request Labeler Signal") runs on `pull_request` with the default types (`opened`, `synchronize`, `reopened`, the same as before). It has `permissions: {}`, checks nothing out and runs one `echo`. - `labeler.yml` now runs on `workflow_run` of that workflow only, so it always runs from `master`. It sets `permissions: {}` at the top and grants the job `contents: read` and `pull-requests: write`, as before. It checks that the triggering event is `pull_request`, validates `head_sha` as 40 hex characters, passes it through `env:` and finds the open PR with `gh pr list --search <sha>` filtered on `headRefOid`. It then runs `actions/labeler@v7` with `pr-number`. The labeler config is still read through the API from `master`. Nothing from the PR is checked out or executed. - `actions/labeler` reads `head-branch` from the `pull_request` event payload, which a `workflow_run` does not have, so the `Backport` rule would never match. The rule moves out of `.github/labeler.yml` into a step that adds `Backport` when `workflow_run.head_branch` starts with `backport`. The branch name is only used in an `if:` expression, never in a shell. `startsWith` ignores case, so `Backport-...` branches now match too. Backport PRs opened by hand, such as #20667 and #20354, depend on this rule. The ones `backport-pr.sh` creates already add the label themselves. The labeler uses search because `GET /repos/{owner}/{repo}/commits/{sha}/pulls` does not return open PRs from forks: it returned nothing for #20690 and #20689. #### Milestone: `push` to `master` `pr-merged.yml` now runs on `push` to `master`. A push event gets a normal token and involves no PR code, so it needs no `workflow_run` pair. The job finds the PR with `GET /repos/{owner}/{repo}/commits/{sha}/pulls` and keeps only a PR merged into `master` whose `merge_commit_sha` is the pushed commit, which covers squash and rebase merges. It passes the number to the unchanged `auto-add-milestone.sh` through `env:` instead of interpolating it into `run:`. A push without a matching PR logs a warning and exits. The checkout now uses `persist-credentials: false`, and the workflow sets `permissions: {}` at the top. #### Behaviour changes - Labels arrive after the signal workflow completes. For fork PRs whose workflow runs need approval, that means after a committer approves the runs, not when the PR opens. - GitHub does not run `pull_request` workflows while a PR has a merge conflict, so a conflicted PR gets new labels only once the conflict is resolved. - The labeler no longer shows up as a check on the PR. Its runs are listed under Actions as "Pull Request Labeler". - PRs into release branches are labelled with `master`'s `.github/labeler.yml`. - `workflow_run` only fires for workflows on the default branch, so this PR cannot exercise the new labeler. Merging it is also the first run of the new milestone workflow. #### Release branches The signal runs from the PR's own code, so PRs into a release branch only get labels if that branch has `labeler-signal.yml`. `38.0.0` and `39.0.0` do not, and they, like `36.0.0` and `37.0.0`, still use `pull_request_target` in `labeler.yml` (and `pr-merged.yml` from 37 on). This PR should be backported to the active release branches, at least `38.0.0` and `39.0.0`. Without that, backport PRs, which the `Backport` rule exists for, go unlabelled once the trigger is turned off. On a release branch the new `labeler.yml` and `pr-merged.yml` do nothing, because `workflow_run` and the `push` trigger only act on `master`. #### Testing - `actionlint` 1.7.12 with shellcheck passes on all three workflows. - I ran the lookup steps locally against apache/druid with a read-only token. Fork PR #20690 resolves to its number, an old commit with no open PR yields no number, and a malformed SHA fails the step. For fork PRs, `workflow_run.head_branch` is the fork's branch name: the "PR Commit Checks" runs for #20690 report `remove-unreferenced-license-files`. The merge commits of #20530 and #20476 resolve to those PRs, and a PR head commit that is not a merge commit logs the warning. - End-to-end run in a scratch repository: pending, results to follow. <hr> This PR has: - [x] been self-reviewed. -- 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]
