ChanServ changed the topic of #freedesktop to: https://www.freedesktop.org infrastructure and online services || for questions about freedesktop.org projects, please see each project's contact || for discussions about specifications, please use https://gitlab.freedesktop.org/xdg or xdg@lists.freedesktop.org
Haaninjo has quit [Quit: Ex-Chat]
pendingchaos_ has joined #freedesktop
pendingchaos has quit [Ping timeout: 480 seconds]
pendingchaos has joined #freedesktop
pendingchaos_ has quit [Ping timeout: 480 seconds]
<eric_engestrom>
"Merge request pipeline #784926 passed for 32788b82 19 minutes ago" but marge isn't merging it
<daniels>
karolherbst: it's a single password rather than giving your user permissions - you can ping Lyude/bskeggs for it
<daniels>
eric_engestrom: it's lost the race and picked the wrong pipeline
AbleBacon has quit [Remote host closed the connection]
agd5f has joined #freedesktop
<eric_engestrom>
ah right, I remember seeing you guys talk about that issue
<eric_engestrom>
do we still need to run all the tests _after_ merging into main? direct pushes are blocked, right?
<eric_engestrom>
(direct pushes into main, I mean)
MrCooper_ is now known as MrCooper
<MrCooper>
eric_engestrom: this is about Mesa I presume?
<eric_engestrom>
yes, forgot to specify
<MrCooper>
all tests don't run for every MR merged, but at least the container jobs need to run if there have been any changes to the CI configuration, to make sure the images are up to date in the main registry
<MrCooper>
I guess build & test jobs could be made manual in post-merge pipelines
<jenatali>
eric_engestrom: I don't think direct pushes are technically blocked, just discouraged
<eric_engestrom>
the container jobs we need, it's the test jobs that I think we should skip (or keep but as manual jobs)
<eric_engestrom>
jenatali: I think it's been long enough, everyone is ok with using MRs to merge stuff, we should disable direct pushes to main
jarthur has joined #freedesktop
<MrCooper>
right, though the majority of post-merge pipelines shouldn't run any jobs, and the number of post-merge pipelines should be smaller than pre-merge, so I don't think it'll make a big difference in the grand scheme of things
<jenatali>
I don't disagree. I've seen it used a few times since I've been on the project but I don't think any of them were justified
<MrCooper>
I think I was advocating for that years ago at this point :)
<MrCooper>
(not allowing direct pushes to main)
<eric_engestrom>
I've done direct pushes a couple of years ago for making mesa branchpoints, but we now go through MRs and whatever lands becomes the branchpoint
<eric_engestrom>
could an Owner or Maintainer of the mesa group have a look to confirm it's not already disallowed before I send an email to the ML to start that discussion?
<eric_engestrom>
MrCooper: ok, if usually the post-merge pipeline doesn't run the tests, then I don't care much if the rules aren't written perfectly and sometimes they still run :]
<jenatali>
The "merge" button for MRs is also problematic, since we want everything to go through Marge, but I don't think that can be disabled / limited to Marge
<eric_engestrom>
yeah, I remember there's an open request at gitlab for that
<MrCooper>
if developer access to main is disabled, doesn't that affect the merge button as well?
<eric_engestrom>
more specifically, for adding/removing specific rights from groups
<jenatali>
Yeah but then Marge couldn't merge
<MrCooper>
she's an admin
<eric_engestrom>
yeah making it Maintainer+ should do the trick
<jenatali>
Ah ok
<eric_engestrom>
still like 10-15 people who are Maintainer who could direct push, but it's still better
<MrCooper>
yep, those are supposed to know better :)
<Mithrandir>
does gitlab have a concept of required statuses to merge? You could have one that marge sets immediately before merging/as part of merging.
jarthur has quit [Ping timeout: 480 seconds]
<daniels>
yeah, we already have that
ximion has joined #freedesktop
<mupuf>
MrCooper: FYI, I am about to start working on post merge testing for radv. So I can have a look at having premerge jobs being manual when merged
<mupuf>
And I would like to skip the compilation jobs if the mesa tarball is already in minio
<mupuf>
Should make post merge testing mostly free from an FD.o PoV
jarthur has joined #freedesktop
<mupuf>
At the very least, it will be cheaper than us maintaining a fork
<daniels>
bentiss: nice! last I saw, the podman support wasn't there yet, so good that it's happened :)
<bentiss>
yeah, trying that thing because harbor did helped a bit, but the past 2 weeeks we still have 2 times mesa pulls than gstreamer
<bentiss>
(it was 4 times before)
agd5f has quit [Ping timeout: 480 seconds]
Leopold_ has quit [Ping timeout: 480 seconds]
agd5f has joined #freedesktop
<bentiss>
daniels: https://paste.centos.org/view/a3d03859 -> this is all I did on m3l-10 to test podman on the test runner I have here (still not migrated the plain docker)
<bentiss>
daniels: tomorrow I'll probably try to switch the main runner to podman after I wiped docker from the disk
Leopold_ has joined #freedesktop
Lyude has joined #freedesktop
<mupuf>
Weird, we've been using podman as a container engine for over a year now
<mupuf>
Way before podman 4
<mupuf>
And speaking about podman, there was a regression introduced in 4.3 which I fixed. I must say the process was relatively painless
<mupuf>
So, if you need to upstream a patch for podman, it's relatively easy
agd5f has quit [Read error: Connection reset by peer]
<mupuf>
Oh, I see, they meant using rootless podman! That is indeed sweet, I'll do that in our infra :)
agd5f has joined #freedesktop
agd5f has quit [Remote host closed the connection]
agd5f has joined #freedesktop
agd5f has quit [Remote host closed the connection]
agd5f has joined #freedesktop
AbleBacon has joined #freedesktop
mvlad has quit [Remote host closed the connection]