08:39 <daniels> It’s done separately from kemper since we never moved it

09:57 <kusma> Did scheduled pipelines on gitlab break around two weeks ago?

09:57 <kusma> https://gitlab.freedesktop.org/freedesktop/planet.freedesktop.org/-/pipelines

09:58 <kusma> There's one scheduled to run in ~5 minutes, but that one should have been run hourly for the last two weeks, I believe...

10:00 <kusma> Oh no, that happened after I renamed master to main 🤦

10:19 <eric_engestrom> bentiss: I'm not a maintainer in the mesa group so I can't check the settings

10:20 <bentiss> eric_engestrom: well, it's empty, but as daniels said above, it was configure on kemper. Not sure I can access it

10:20 <eric_engestrom> daniels: in that mirroring script, any chance to only push if the branch is one of (main|amber) ? the rest of them have no reason to be mirrored

10:21 <eric_engestrom> bentiss: yup, I was just saying for future reference :)

10:21 <bentiss> heh OK

10:24 <daniels> eric_engestrom: look in /srv/git.freedesktop.org/git/mesa/mesa.git/hooks/post-receive.d/

10:24 <daniels> I’m not really near my laptop today so good luck

10:24 <daniels> I’m not really sure what the point of having a partial mirror is though?

10:25 <eric_engestrom> yup, found it as /git/mesa/mesa.git/hooks/post-receive.d/ but I expect it's the same dir through different symlinks

10:25 <daniels> I’d have no issue deleting it but not sure what problem it solves if we’re mirroring two branches but not the ones with the releases

10:25 <eric_engestrom> sure, we can add the release branches to that filter

10:25 <eric_engestrom> but I regularly have to delete branches that people creates on the main repo for MRs, for instance

10:26 <daniels> oh

10:26 <eric_engestrom> those got deleted on gitlab but not in the mirror

10:26 <daniels> we can fix that on GitLab I’m pretty sure

10:27 <daniels> yeah, in the protected branches settings, just add a filter for * and make it so that no-one can push

10:28 <eric_engestrom> daniels: that would prevent release maintainers from working on `staging/X.Y` and `X.Y`, wouldn't it?

10:28 <eric_engestrom> although perhaps the answer is that we should stop doing that and figure out another process?

10:30 <daniels> I still don’t understand how the staging branch stuff makes sense tbh, but when you have multiple matches, most-permissive applies https://gitlab.freedesktop.org/help/user/project/protected_branches#configure-multiple-protected-branches-by-using-a-wildcard

10:30 <eric_engestrom> this /git/bin/signal-github-mirror which echoes into /run/github-mirror/named-pipe reminds me that there's a daemon that runs to read through that name pipe; the pipe is there, but I'm not sure how to check for the daemon (lsof on that file returns nothing)

10:30 <daniels> so just add one for staging to the existing rules and you’ll be fine

10:31 <daniels> the daemon is a systemd unit

10:33 <eric_engestrom> github-mirror.service is up and running, but I don't have rights to try to restart it

10:35 <daniels> ok, I’ll look at it when I’m next near my laptop

11:25 <eric_engestrom> thanks :)

11:25 <eric_engestrom> (it's been dead for 3+ weeks so there's no rush)