07:37 <MrCooper> hmm, why did MR Label Maker discover https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22517 only just now

09:02 <pinkflames[m]> Excuse a possible double post, if someone already asked this but we just got Error 500 for a CI image: https://gitlab.freedesktop.org/pipewire/pipewire/-/jobs/40167813

09:04 <pinkflames[m]> What exactly went wrong and what if anything can I do about it?

09:13 <mupuf> pinkflames[m]: nothing wrong on your side, you must have hit an unlikely event

09:25 <pinkflames[m]> Thanks for confirming. I guess I have some of the worst luck one could possibly have and still live :/

09:27 <mupuf> pinkflames[m]: this is not your fault, networks spanning the globe are a little unreliable

09:28 <mupuf> but in this case, it is likely that gitlab was being restarted or something like that

09:28 <pinkflames[m]> :)

09:38 <gkiagia> shouldn't the registry cleanup policy be enabled for projects? I was just looking at deleting some old images in pipewire and realized that I can't set them to automatically be removed after some time because the cleanup feature is disabled

10:35 <daniels> MrCooper: mr-label-maker gets kicked on every MR creation or update; assigning it to marge bot is an update so it processed it then

10:35 <daniels> why it didn't process it before I have no idea

14:12 <Venemo> kudos to the person who invented Mr. label maker

14:34 <daniels> mslusarz: ^

15:10 <mslusarz> daniels: given that webhook payload processing was implemented and setup recently my guess would be that this part is somehow broken - in polling mode it wouldn't be possible for it to miss just this MR...

15:11 <mslusarz> hmm, there's more such MRs

15:13 <MrCooper> could it be that the webhook ran "too early", before the MR changes were visible?

15:18 <mslusarz> It's possible. I noticed that GitLab have some lag recently - One time comment notification (over email) arrived few minutes earlier before it was visible in the UI. Another time MR showed 0 commits for few minutes after force push.

15:33 <mslusarz> I confirmed that MRs 22537 22458 22361 22543, which currently are without labels, would be correctly tagged in polling mode

15:40 <mslusarz> It's weird that MR 14598, created more than a year ago, also doesn't have labels, when locally mr-label-maker can determine the correct label :/

15:43 <mslusarz> daniels: I wonder, when it was initially setup, did you use "--label none" parameter to filter out already labeled mrs/issues? because the only way I could see it skipping this MR is if all mrs were processed with some small timeout...

15:45 <daniels> mslusarz: it just ran mr_label_maker --project=mesa --merge-requests --poll=60

15:45 <mslusarz> lol, even without --state opened?

15:46 <mslusarz> that would explain the push for webhook handling

15:47 <mslusarz> this finishes in 7 seconds: ~/.local/bin/mr_label_maker --project mesa --token "$TOKEN" --state opened --merge-requests --dry-run

15:47 <mslusarz> I mean with --label none

15:49 <mslusarz> without it it takes forever (I killed it after 3 minutes)

15:49 <daniels> it never showed as a performance issue

15:49 <daniels> the webhook stuff was just that bentiss/whot were already working on webhooks and wanted to centralise stuff

16:40 <bentiss> daniels, mslusarz: TBH, I think the easiest would be to have mr-label-maker add a label on the MR it processed "mr-label-marked", and if it is removed, it forces the relabelling (thus skipping the "history of labels then skip relabeling"). This would allow to ask for a re-labelling from the users/maintainers

16:41 <bentiss> and of course, if "mr-label-marked" is present, it ignores the MR

16:42 <bentiss> and I will not have time to work on that, but FWIW, as soon as this change is merged in fdo/mr-label-maker, it will redeploy automatcially, so it's just a python change away... just saying... :)

18:28 <pinkflames[m]> Has Gitlab's domains or cookies changed? My Firefox suddnely longer seems to remember the session token. Other websites seem to be fine, so it's only FDO that's affected

21:52 <jenatali> Hm, I'm seeing my fork re-creating container images that should be getting re-used from upstream. Specifically: https://gitlab.freedesktop.org/jenatali/mesa/-/jobs/40220875

22:00 <eric_engestrom> DavidHeidelberg[m]: ^ possible fallout from !22386 ?