Add s/triaged label for issues opened by (core) team (#22006)

* Add s/triaged label for issues opened by (core) team

Alternate approach to #21775 as that clearly didn't work. Hoping this _will_ work!

From the original PR:

> Adds a rule to the bot that adds the s/triaged label to an issue which is opened by the core team (someone with write permissions on the repo). A lot of times these issues are tasks and/or very cryptic to the triage team. This way, the triage team will skip these issues and we assume the issues are valid ones and/or not issues that need triage.

* Update resourceManagement.yml
This commit is contained in:
Gerald Versluis 2024-04-23 23:55:02 +02:00 коммит произвёл GitHub
Родитель 994117b207
Коммит 17b05bc4bb
Не найден ключ, соответствующий данной подписи
Идентификатор ключа GPG: B5690EEEBB952194
1 изменённых файлов: 38 добавлений и 3 удалений

41
.github/policies/resourceManagement.yml поставляемый
Просмотреть файл

@ -581,13 +581,48 @@ configuration:
description: Remove 's/try-latest-version' when new reply from author comes in
- if:
- payloadType: Issues
- activitySenderHasPermission:
permission: Write
- isAction:
action: Opened
- or:
- isActivitySender:
user: PureWeen
issueAuthor: False
- isActivitySender:
user: mattleibow
issueAuthor: False
- isActivitySender:
user: rmarinho
issueAuthor: False
- isActivitySender:
user: jsuarezruiz
issueAuthor: False
- isActivitySender:
user: Redth
issueAuthor: False
- isActivitySender:
user: StephaneDelcroix
issueAuthor: False
- isActivitySender:
user: samhouts
issueAuthor: False
- isActivitySender:
user: jamesmontemagno
issueAuthor: False
- isActivitySender:
user: jonathanpeppers
issueAuthor: False
- isActivitySender:
user: rachelkang
issueAuthor: False
- isActivitySender:
user: Eilon
issueAuthor: False
- isActivitySender:
user: jfversluis
issueAuthor: False
then:
- addLabel:
label: s/triaged
description: Add 's/triaged' label to issues opened by the core team, we assume these issues do not need triaging
description: Add 's/triaged' label to issues opened by the (core) team, we assume these issues do not need triaging
onFailure:
onSuccess: