comphead commented on code in PR #7482: URL: https://github.com/apache/datafusion-comet/pull/7482#discussion_r4470290514
########## .github/workflows/label_prs_trigger.yml: ########## @@ -0,0 +1,36 @@ +# Licensed to the Apache Software Foundation (ASF) under one +# or more contributor license agreements. See the NOTICE file +# distributed with this work for additional information +# regarding copyright ownership. The ASF licenses this file +# to you under the Apache License, Version 2.0 (the +# "License"); you may not use this file except in compliance +# with the License. You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, +# software distributed under the License is distributed on an +# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +# KIND, either express or implied. See the License for the +# specific language governing permissions and limitations +# under the License. + + +name: Label pull requests trigger + +# Starts the labeler for a pull request. This run gets a read-only token and does nothing itself; +# when it completes, label_prs.yml runs from the default branch through workflow_run and writes +# the labels. Kept separate from Comet CI so labels arrive in seconds rather than after CI. +on: + pull_request: Review Comment: 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`? ########## .github/workflows/label_prs.yml: ########## @@ -15,73 +15,101 @@ # specific language governing permissions and limitations # under the License. + name: Label pull requests -# Runs on pull_request_target so it can label pull requests from forks. Nothing from the pull -# request is checked out or executed: the labeler reads the changed file list through the API -# and the title step reads the event payload. +# Labels a pull request after label_prs_trigger.yml runs for it. GitHub blocks +# pull_request_target on public repositories, and a pull_request run from a fork only gets a +# read-only token, so the labels are written here: workflow_run runs this file from the default +# branch with a token that can write them. Nothing from the pull request is checked out or +# executed, and nothing its run produced is read. The pull request is looked up from the run's +# head repository, branch and commit, and its title, labels and changed files come from the API. on: - pull_request_target: - types: [opened, synchronize, reopened] + workflow_run: + workflows: [Label pull requests trigger] Review Comment: 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? -- 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]
