[Backport release-25.05] workflows/labels: manage approval labels#416410
Merged
philiptaron merged 7 commits intorelease-25.05from Jun 14, 2025
Merged
[Backport release-25.05] workflows/labels: manage approval labels#416410philiptaron merged 7 commits intorelease-25.05from
philiptaron merged 7 commits intorelease-25.05from
Conversation
2 tasks
Contributor
|
Backport on hold until we have looked into #415259 (comment) a bit more. |
This brings back the "minimize CI reviews after dismissal" job that was previously removed. The first time around, we had a single job triggered by the `pull_request_review` event. This lacks permission to do meaningful stuff, though. This time, we trigger an empty no-op job on `pull_request_review` and then run a second workflow on `workflow_run`. This can run with the proper permissions. (cherry picked from commit a34a22d)
This moves the actual labeling from the eval workflow to the labels workflow. At this stage, this only has a disadvantage: Adding the topic-labels to the pull request will now only happen after eval has finished, instead of instantly. We will only benefit from this later, when we manage approval related events. With this change, we will have the comparison results and thus the package maintainer info available. (cherry picked from commit 2d0bcd7)
The category 12 labels for number of approvals and approved by package maintainer are now automatically managed by the labels workflow. The logic is slightly different from the "by: package-maintainer" label. For approval, it's enough if *any one* maintainer approves the PR to have the label added, even if the PR touches multiple packages. The workflow only counts approved reviews, no matter whether there had been a push in the meantime or not. To achieve the currently used logic of "expiring approvals after push", we will have to set up a branch protection rule, which actually dismissed those reviews automatically. (cherry picked from commit 5f09e16)
This can happen when two PRs run at the same time, which come from different forks, but have the same head branch name. github.head_ref is suggested by GitHub's docs, but.. that's not really useful for cases with forks. (cherry picked from commit 7ba7720)
…lows This didn't work as intended. When a workflow is run with `workflow_call`, it will have `github.workflow` set to the *parent* workflow. So the `caller` input that we passed, resulted in this concurrency key: ``` Eval-Eval-... ``` But that's bad, because the labels and reviewers workflows will cancel each other! What we actually want is this: - Label and Reviewers workflow should have different groups. - Reviewers called via Eval and called directly via undraft should have *different* groups. We can't use the default condition we use everywhere else, because `github.workflow` is the same for Label and Reviewers. Thus, we hardcode the workflow's name as well. This essentially means we have this as a key: ``` <name-of-running-workflow>-<name-of-triggering-workflow>-<name-of-event>-<name-of-head-branch> ``` This should do what we want. Since workflows can be made reusable workflows later on, we add those hardcoded names to *all* concurrency groups. This avoids copy&paste errors later on. (cherry picked from commit 6793e23)
d4787fe to
4aa51a9
Compare
A single reviewer approving a Pull Request multiple times should only count once. (cherry picked from commit 2e03351)
2 tasks
This currently fails with: ``` Method Set.prototype.has called on incompatible receiver undefined ``` Seems like my syntax test previously only hit the case without maintainers, in which case it doesn't throw :/. (cherry picked from commit 4b9fb45)
philiptaron
approved these changes
Jun 14, 2025
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bot-based backport to
release-25.05, triggered by a label in #415259.