Stop team label processor from reacting to gitlab bot events
What does this MR do and why?
Addresses the 2nd part of the bug described in #1126 (comment 1103836787)
Closes #1126 (closed) closes #1130 (closed)
My investigation with gitlab-org/gitlab#374098 (closed) receiving duplicated section and devops labels is the following:
By looking at the resource_label_events
api response, the following label events happened first:
- developer added
group::foundations
andmaintenance::refactor
labels, at the exact time stamp, which tells me they were added with the/label
quick action in the comment2022-09-16T12:29:02.039Z
:
{
"id": 186578521,
"user": {
...
"username": "pgascouvaillancourt",
},
"created_at": "2022-09-16T12:29:02.039Z",
...
"label": {
...
"name": "group::foundations",
},
"action": "add"
},
{
"id": 186578522,
"user": {
...
"username": "pgascouvaillancourt",
},
"created_at": "2022-09-16T12:29:02.039Z",
...
"label": {
"name": "maintenance::refactor",
...
},
"action": "add"
},
- Because
maintenance::refactor
triggered a type label automation to addtype::maintenance
, the gitlab-bot went ahead and added the type label, before thesection
anddevops
labels were added, at2022-09-16T12:29:02.816Z"
:
{
"id": 186578530,
"user": {
...
"username": "gitlab-bot",
},
"created_at": "2022-09-16T12:29:02.816Z",
...
"label": {
...
"name": "type::maintenance",
},
"action": "add"
},
- Due to the above 2 label update events both occurred when
devops
andsection
labels are missing, they subsequently both invoked the team label inference processor to apply the missing scoped labels, first time at2022-09-16T12:29:03.468Z
, then at2022-09-16T12:29:03.488Z
, just milliseconds apart:
{
"id": 186578543,
"user": {
...
"username": "gitlab-bot",
},
"created_at": "2022-09-16T12:29:03.468Z",
...
"label": {
...
"name": "devops::ecosystem",
},
"action": "add"
},
{
"id": 186578544,
"user": {
"username": "gitlab-bot",
...
},
"created_at": "2022-09-16T12:29:03.468Z",
"label": {
...
"name": "section::dev",
},
"action": "add"
},
{
"id": 186578545,
"user": {
"username": "gitlab-bot",
},
"created_at": "2022-09-16T12:29:03.488Z",
"label": {
"name": "devops::ecosystem",
...
},
"action": "add"
},
{
"id": 186578546,
"user": {
...
"username": "gitlab-bot",
},
"created_at": "2022-09-16T12:29:03.488Z",
"label": {
"name": "section::dev",
...
},
"action": "add"
}
The solution is to just let the team label inference processor skip the gitlab bot event, so this scenario will no longer happen.
Expected impact & dry-runs
These are strongly recommended to assist reviewers and reduce the time to merge your change.
See https://gitlab.com/gitlab-org/quality/triage-ops/-/tree/master/doc/scheduled#testing-with-a-dry-run on how to perform dry-runs.
Action items
-
(If applicable) Add documentation to the handbook pages for Triage Operations => - (If applicable) Identify the affected groups and how to communicate to them:
-
/cc @ person_or_group
=> -
Relevant Slack channels => -
Engineering week-in-review
-
Edited by Jennifer Li