ChanServ changed the topic of #freedesktop to: infrastructure and online services || for questions about projects, please see each project's contact || for discussions about specifications, please use or
busheling has left #freedesktop [Leaving]
Leopold_ has quit [Remote host closed the connection]
Guest6707 has quit [Read error: Connection reset by peer]
peelz has joined #freedesktop
peelz is now known as Guest7620
Leopold__ has joined #freedesktop
jarthur has quit [Ping timeout: 480 seconds]
Haaninjo has quit [Quit: Ex-Chat]
Haaninjo has joined #freedesktop
columbarius has joined #freedesktop
Haaninjo has quit [Quit: Ex-Chat]
co1umbarius has quit [Ping timeout: 480 seconds]
Kayden has joined #freedesktop
agd5f_ has joined #freedesktop
agd5f has quit [Ping timeout: 480 seconds]
rcampbell has quit []
BlkPoohba has joined #freedesktop
strugee has quit [Quit: ZNC -]
strugee has joined #freedesktop
ximion has quit [Quit: Detached from the Matrix]
K`den has joined #freedesktop
Kayden has quit [Read error: Connection reset by peer]
BlkPoohba has quit []
BlkPoohba has joined #freedesktop
K`den is now known as Kayden
BlkPoohba has quit []
BlkPoohba has joined #freedesktop
BlkPoohba has quit []
BlkPoohba has joined #freedesktop
BlkPoohba has quit []
BlkPoohba has joined #freedesktop
harishnkr has joined #freedesktop
BlkPoohba has quit []
harishnkr has quit []
BlkPoohba has joined #freedesktop
BlkPoohba has quit []
BlkPoohba has joined #freedesktop
BlkPoohba has quit []
BlkPoohba has joined #freedesktop
BlkPoohba has quit []
chip_x has quit [Ping timeout: 480 seconds]
<mupuf> bentiss: the wget command probably needs to be put in a loop
<mupuf> that being said, I fully agree with having a script like this
* mupuf just removed his, but I guess something equivalent could be reintroduced for test machines
BlkPoohba has joined #freedesktop
BlkPoohba has quit []
BlkPoohba has joined #freedesktop
robobub has joined #freedesktop
BlkPoohba has quit []
BlkPoohba has joined #freedesktop
BlkPoohba has quit []
BlkPoohba has joined #freedesktop
agd5f has joined #freedesktop
Haaninjo has joined #freedesktop
agd5f_ has quit [Ping timeout: 480 seconds]
danvet has joined #freedesktop
BlkPoohba has quit []
BlkPoohba has joined #freedesktop
<bentiss> mupuf: I need more context. I'm not following you
<mupuf> bentiss: in, `wget -q` should be attempted a couple of times so that a short network outtage doesn't fail jobs
<mupuf> the best thing would be to cache it, and just try to update it in every job (and use the cache if it failed)
BlkPoohba has quit []
BlkPoohba has joined #freedesktop
<bentiss> mupuf: cache doesn't work because we don't have much control over the container that is spawned at this time
<bentiss> IIRC
<bentiss> agree on the loop
<bentiss> I think today I'll set this one in place
<mupuf> thanks a lot!
<mupuf> We don't deserve you...
<bentiss> daniels: I will probably rename some of the repos we are using: helm-gitlab-omnibus -> helm-gitlab-deployment for a start
BlkPoohba has quit []
BlkPoohba has joined #freedesktop
<daniels> bentiss: sure! go ahead
<bentiss> daniels: already done :)
<bentiss> daniels: I'm also renaming the branch master into main
<daniels> yeah nice
<bentiss> because it's painful to have either master or main depending off the project
<daniels> srsly
AbleBacon has quit [Read error: Connection reset by peer]
<bentiss> daniels: I'm now splitting helm-gitlab-config in 2 (3?) -> helm-infra-deployment and fdo-bots
<bentiss> I'll try to keep the history in both
<bentiss> ideally, I might just rename helm-gitlab-config into fdo-bots and respin helm-infra-deployment from a new project. This way if others want to look for marge config, they'll get redirected
<daniels> do many people go looking for Marge config? tbh I’ve probably linked gitlab-runner provisioning the most
<daniels> turns out it wasn’t a great example tho so maybe it is best to break those links :P
<bentiss> k, 2 new projects it is
BlkPoohba has quit []
BlkPoohba has joined #freedesktop
BlkPoohba has quit []
BlkPoohba has joined #freedesktop
mvlad has joined #freedesktop
MajorBiscuit has joined #freedesktop
agd5f_ has joined #freedesktop
<daniels> awesome
<bentiss> and is renamed from -config, and pruned from marge-bots
BlkPoohba has quit []
agd5f has quit [Ping timeout: 480 seconds]
BlkPoohba has joined #freedesktop
<bentiss> daniels, mupuf, anybody else: I have enabled runner-gating on ml-13. If it goes OK-ish, I'll enable it for the rest of the fleet
<bentiss> damn, it didn't triggered the pre-clone script
<bentiss> I'll check later, bbiab
<mupuf> bentiss: thanks for the notice!
BlkPoohba has quit []
Major_Biscuit has joined #freedesktop
Leopold__ has quit [Remote host closed the connection]
MajorBiscuit has quit [Ping timeout: 480 seconds]
Leopold_ has joined #freedesktop
BlkPoohba has joined #freedesktop
<bentiss> ouch, right now the script doesn't work if GIT_STRATEGY: none
<bentiss> because it's a "pre_get_sources_script", not "pre_anything" :(
<sergi> mupuf, bentiss: about the wget and the retries. We often replace wget by curl with parameters to retry like `alias curl="curl -L --retry 4 -f --retry-all-errors --retry-delay 60"` in
<bentiss> sergi: when we are at this time, we are in a container image that doesn't have curl
<sergi> :(
<bentiss> yep :)
<mupuf> sergi: BTW, I removed the restriction for running jobs in the valve farms
<mupuf> I need to remove the restriction in Mesa
BlkPoohba has quit []
BlkPoohba has joined #freedesktop
<bentiss> haha! there is a `pre_build_script` I can use instead
<bentiss> though we might be in the container, so now wget and bash are probably not guaranteed
<sergi> mupuf, has this any relation with about ^zink-radv-.*-valve jobs? ci-uprev is not yet triggering those jobs because they aren't created when it test a piglit uprev
<mupuf> bentiss: yep, that's what I have been using
<mupuf> sergi: yes :)
<mupuf> sergi: review appreciated ;)
<mupuf> I would like to merge this series ASAP
<bentiss> ml-13 pre-build-script disabled for now, we need a curl/wget backup or some images will just fail
<mupuf> bentiss: so... we need a statically-compiled script?
<mupuf> maybe something written in go or rust?
<mupuf> this way we could inject that in any container, without having to care about dependencies?
<bentiss> mupuf: oh, you mean mount it as a voilume?
<mupuf> yes! That's what I do :)
* bentiss needs to think of it then
<mupuf> except it is still a shell script for me (but it has no dependencies)
<bentiss> I like the idea (using a mount volume), but I need to think at how I can automatically update it on the runner
BlkPoohba has quit []
BlkPoohba has joined #freedesktop
<sergi> mupuf, but sorry, is this restricting to have those jobs only in "mesa/mesa"? The uprevs are prepared in a branch in a fork. Before proposing an uprev by creating a merge request, it is testing the uprev and amending it if there are expectation changes. This way this will not be allowed. I'm thinking in change the flow in ci-uprev to adapt to that
<mupuf> sergi: that's how it *was*. I got rid of limitation, for you
<mupuf> (and other developers who were hellaconfused)
<mupuf> I will likely reintroduce it when bentiss and I figure out something that works for everyone
<sergi> mupuf agh sorry. I misinterpreted merge request. My mind read like those lines stay there, when in fact they are removed. Sorry
<mupuf> the current way I was doing it was a allowlist in every farm
<mupuf> ;)
<mupuf> be back in a couple of hours
<bentiss> mupuf: silly idea: I mount the host curl command in the container to a known path :)
Leopold___ has joined #freedesktop
Leopold_ has quit [Ping timeout: 480 seconds]
<bentiss> damn, I need a statically compiled curl :(
<__tim> There must be a little rust tool that can do the job somewhere surely
MajorBiscuit has joined #freedesktop
<bentiss> seems to be working, and we can probably just rebuild curl from our .gitlab-ci
<bentiss> MIT :)
Major_Biscuit has quit [Ping timeout: 480 seconds]
Haaninjo has quit [Quit: Ex-Chat]
BlkPoohba has quit []
<mupuf> bentiss: yeah, this is why I was proposing rust or go
<mupuf> Moparisthebest :D
mohamexiety has joined #freedesktop
<mupuf> daniels, DavidHeidelberg[m]: Seems like valve infra wasn't the only one hit by the XDG_RUNTIME issue:
vbenes has quit [Ping timeout: 480 seconds]
<daniels> mupuf: yeah, so guess it would be the same fix there - either tell dEQP to not bother trying to use Wayland as a platform (not sure if there's an env variable or something?), or run it under Weston
<daniels> mupuf: if you've got some time that would be magnificent; I'm not going to have time today as I've got a lot of stuff to clear out before I go on holiday Thurs-Mon inclusive
<mupuf> or set the variable and make sure the folder exists
<mupuf> enjoy your holiday!
<daniels> thanks!
* mupuf will try to clear some time for that... but he is also preparing for 3 weeks of ... parental leave
<daniels> and yeah, init-stage2 could just do the export XDG_RUNTIME_DIR="$(mktemp -d -m 0700)" or whatever
<daniels> ahhh fun
<mupuf> init-stage2 could just do the export XDG_RUNTIME_DIR="$(mktemp -d -m 0700)" or whatever --> Yeah, done that already, but this job does not use init-stage2
<mupuf> same as valve infra, it was hardcoding the deps
<daniels> oh ofc, it's swrast
vbenes has joined #freedesktop
<mupuf> ;)
<mupuf> it can still use stage2 though, no harm done
<daniels> yeah, it would definitely be nice to keep on making as much stuff as we can common and predictable through there
<daniels> I spent a bunch of time doing the initial init unification to make LAVA and bare-metal coherent a while ago, but lost momentum (and/or the will to live) after that
<mupuf> I am not surprised
<mupuf> and it is bound to diverge... unless we start from the top, right?
<mupuf> Will be fun to try running b2c on lava :p
<mupuf> we are almost done adding support for arm64 to valve infra (it works in our developer environment where the infra is simulated in a VM, and I b2c boots on a RPI 4 using EFI)
<mupuf> but it is not plug-and-play juuuust yet
vkareh has joined #freedesktop
mohamexiety has quit [Remote host closed the connection]
<daniels> nice :)
<daniels> mupuf: ooi what do you mean by 'removing the need for the gitlab runner'?
Leopold has joined #freedesktop
Leopold___ has quit [Remote host closed the connection]
<mupuf> daniels: I mean that my "executor" service would be the one talking to gitlab directly
<daniels> right, so still a gitlab runner, but just not using gitlab-runner
<mupuf> yes
<mupuf> :)
<daniels> we're doing the same for LAVA and there's something decent coded up for it (in Rust even), but it's on the backburner whilst we're sorting out a few other things like artifact storage
<mupuf> and when we are done with that, we'll add support for other forges
<mupuf> yes, you opened my eyes to that :)
<mupuf> I was expecting it to be a disaster... but it didn't look that bad
<mupuf> what I think we'll gain from that: 1. never starting 2 jobs at the same time for the same runner; 2. faster execution time; 3. making running on hardware look exactly the same as running in the cloud
<mupuf> (sure, you can set some variables to specify the kernel, add kernel command line arguments, ..., but for simple jobs, everything would work well by default)
vbenes has quit [Quit: Leaving.]
vbenes has joined #freedesktop
<daniels> yeah exactly, removing the indirection sure would be nice, and definitely gives us a lot more scope to simplify things and make the three different DUT handlers look more similar
<mupuf> For instance, I stopped using dnsmasq in the past month and vendored pypxe in the executor: I can now serve the most appropriate kernel based on the DHCP request!
<mupuf> and that also means I can automatically reboot the machine if it did not issue any DHCP request within the expected time it usually takes to boot
<mupuf> and this value can be learnt during our training phase (what happens when you enroll a new machine, or when its tags changed)
<mupuf> but yeah, removing the indirection will be a great boost to bare metal CI adoption
<mupuf> I am planning on having a workshop in the next XDC on how to deploy one. I'll come with some hardware
<daniels> arm certainly makes it easier to bring hardware at least :P
<mupuf> exactly, and I can ask people to bring their boards too!
<mupuf> curPageLogUid=6oFiTb2JuZ8k
<mupuf> for ~250 euros, you can get 4x2.5G ports, wifi, nvme drive, and 8 GB of RAM (when on sale)
<mupuf> and this is fully fanless and consuming ~8W at idle
<mupuf> I bought one for my home router, and one for replacing my current gateway which consumes 8 times as much
agd5f has joined #freedesktop
agd5f_ has quit [Ping timeout: 480 seconds]
<daniels> yeah, the problem with arm-based routers is that they're often cripplingly limited for I/O, which is sort of not good
<bentiss> mupuf: sigh... -> doesn't have /etc/ssl/certs/ca-certificates.crt installed
<bentiss> mupuf: do you have a quick copy/paste I could use to export that cert in the container and use it instead of the defaults?
<mupuf> bentiss: I do not...
* mupuf has it easier... since the script is auto-generated by ansible
<bentiss> yeah, well, I have to account for *any* image :(
<mupuf> exactly
<mupuf> let's check what I ship in b2c
<bentiss> curl --cacert [file]
<bentiss> let's see if that works
<bentiss> looks like it works :)
<mupuf> yeepee!
<mupuf> you are fast!
* bentiss changes the script/commands
* mupuf was taking the cacerts from alpine on b2c creation
MrCooper has quit [Ping timeout: 480 seconds]
MrCooper has joined #freedesktop
<bentiss> daniels: I am tempted to deploy the kill switch on all runner now. I do not see what is the next hiccups we'll have so we should probably target a wider audience
<bentiss> right now, it's just giving a notification at the beginning of the job:
<bentiss> it would fail if sh is not available in the target container... but not sure we can do at that time given that gitlab requires the entrypoint to be sh or bash
<daniels> bentiss: oh nice, yeah I think sh is fine for all but windows obviously - is there anything in particular to know to include outside of the host environment? we could do the same for LAVA/b2c/bare-metal farms too
<bentiss> daniels: so I included in the image through a volume a static curl and the ca-certificates.crt file. That seems to be it
<daniels> yeah, makes sense - the ca-certificates provided in the default runner-helper only has the cert for the service itself
abrotman has quit [Remote host closed the connection]
<bentiss> daniels: actually we are not in pre-clone script now
abrotman has joined #freedesktop
<bentiss> we are in pre-build, which executes just before the before_script, so in the target container
<bentiss> generate-cloud-init is wrong in that regard :)
* bentiss fixes it
<daniels> ahhh, nice!
<bentiss> daniels: what's the plan with m3l-18 and kata-1?
<daniels> bentiss: I have no plan with m3l-18, I thought you were going to burn -15 so I just provisioned 16+17+18 fresh
<daniels> kata-1 I might just destroy for now; a bunch of stuff came up over the past couple of days I couldn't ignore and I'm not going to be able to get Kata done before I go on holiday
<bentiss> daniels: k. well, -13 is still alive, so maybe we want to keep it while it has some cache for jobs
<bentiss> daniels: this is what I run on all runners:
<bentiss> well, assuming the arch is amd64 and that the pre_get_sources_script was already defined
<bentiss> so I'm going to kill kata-1 and m3l-18, just to keep the runners to a reasonable number
<daniels> sounds good!
<bentiss> daniels: k, thanks
<bentiss> OK, the kill switch is installed in all runners I have access to. It's a matter of commenting to enable it
* bentiss waits a bit in case someone screams (though you have to scream a lot to change my mind)
<__tim> and then we wait for people to comment on the ticket to add their projects?
<bentiss> either comment on the ticket or sending MR
<__tim> ah, I didn't see the groups check, sorry
<bentiss> __tim: that script is a baseline. I would be glad to add a smarter check policy, but I personnally add myself as a vip, because I trust myself to not temper the runners, but others can eeasily add more logic
agd5f_ has joined #freedesktop
agd5f has quit [Ping timeout: 480 seconds]
agd5f_ has quit []
agd5f has joined #freedesktop
agd5f_ has joined #freedesktop
agd5f has quit [Ping timeout: 480 seconds]
agd5f_ has quit [Ping timeout: 480 seconds]
agd5f has joined #freedesktop
MajorBiscuit has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #freedesktop
agd5f_ has joined #freedesktop
agd5f has quit [Ping timeout: 480 seconds]
agd5f has joined #freedesktop
agd5f_ has quit [Ping timeout: 480 seconds]
agd5f_ has joined #freedesktop
DodoGTA has quit [Quit: DodoGTA]
AbleBacon has joined #freedesktop
DodoGTA has joined #freedesktop
agd5f has quit [Ping timeout: 480 seconds]
agd5f has joined #freedesktop
agd5f_ has quit [Ping timeout: 480 seconds]
agd5f_ has joined #freedesktop
agd5f has quit [Ping timeout: 480 seconds]
agd5f has joined #freedesktop
DodoGTA has quit [Quit: DodoGTA]
DodoGTA has joined #freedesktop
<bentiss> It's been ~1h30 that the script is deployed without a failure related to it. Enforcing it.
agd5f_ has quit [Ping timeout: 480 seconds]
agd5f_ has joined #freedesktop
DodoGTA has quit [Remote host closed the connection]
<jenatali> I assume there's going to be similar enforcement applied to the Windows runners at some point?
DodoGTA has joined #freedesktop
<kusma> I got a failure here that tells me I'm missing permissions, but the text at the link it pointed to doesn't really seem to match up with what happened:
agd5f has quit [Ping timeout: 480 seconds]
<kusma> The text says "What it means for me, a maintainer of a project part of Hopefully nothing. Contributors should still be able to run CI on the MRs, and you can still have your project being tested as previously."
agd5f has joined #freedesktop
<kusma> But that's not the case. The CI runs in the users namespace, which I guess is what gives the error...
<bentiss> kusma: please see the backlog for (a lot of) context
<bentiss> I have disabled shared runners for personal namespaces, so either you migrate your upstream official projects under a group, either you add yourself as a vip in
<kusma> This is mesa/demos
<kusma> It's under a group already.
<bentiss> kusma: MR pipelines are not enabled in this project
<kusma> What do you mean?
DodoGTA has left #freedesktop [#freedesktop]
<bentiss> -> "The only thing you have to be aware of, is that you need to have detached MR pipelines. For that, just append the following snippet to your .gitlab-ci.yaml"
<kusma> We've been doing MRs with automatic pipelines for a long time... They trigger, but in the user's namespace.
DodoGTA has joined #freedesktop
agd5f_ has quit [Ping timeout: 480 seconds]
<bentiss> yes, but not using MR pipelines. The pipelines are run in the fork, not in the group namespace
<kusma> OK, I see. Well, I don't think I have the permissions needed to add that setting.
<bentiss> Just submit an MR :)
<daniels> bentiss: I think we might want to reword the notification, because 'hacked pretty badly' is going to make people think their data/etc was compromised, as opposed to just we had to deal with a ton of pain
<bentiss> daniels: sure, please do
DodoGTA has left #freedesktop [#freedesktop]
<bentiss> daniels: in the meantime I s/We/Our runners/
<kusma> bentiss: Ah, it's *just* the YAML change?
<bentiss> kusma: yes
<kusma> OK, thanks.
<kusma> That I can do :)
<daniels> bentiss: reworded it slightly so hopefully we get less 'HACKED???' panic
DodoGTA has joined #freedesktop
<bentiss> daniels: thanks :)
agd5f_ has joined #freedesktop
<daniels> np!
<bentiss> sigh, this one should not have failed:
<bentiss> actually I guess this is because the person is not part of the project
<bentiss> so the pipeline needs to be manually triggered by someone from the project
<alatiera> oh it wasn't a fork pipeline btw
<bentiss> oh, the MR was created after the pipline :)
<bentiss> I see...
DodoGTA has left #freedesktop [#freedesktop]
DodoGTA has joined #freedesktop
<bentiss> I guess it's going to be a bumpy ride :(
agd5f has quit [Ping timeout: 480 seconds]
<alatiera> the main issue I see is that for parent pipelines to work the person that opened the mr needs to also have developer permissions
<alatiera> its not enough for a maintainer to trigger the CI
agd5f has joined #freedesktop
<alatiera> it just ends up creating more fork pipelines that way
agd5f_ has quit [Ping timeout: 480 seconds]
agd5f_ has joined #freedesktop
<bentiss> alatiera: this MR is not concerned by the new runner policy...
<alatiera> bentiss I mean, atm that's why your script failed
<alatiera> CI_PROJECT_ROOT_NAMESPACE in a parent pipeline is mesa group, but in a fork pipeline is the user
<alatiera> but I think there's a CI_MR variable, let me check
<bentiss> alatiera: yes, I know that. But if someone from the project runs the pipeline, we are good IIRC
<bentiss> so that means that before running the workload, for external users we will have to actually review that it's not crypto
agd5f has quit [Ping timeout: 480 seconds]
<alatiera> why would we be good if the pipeline is triggered by a maintainer
agd5f has joined #freedesktop
<bentiss> because someone actually reviews the code????
<alatiera> yes but pipeline created will still trip over the root_namespace check no?
<bentiss> AFAIU no
<bentiss> gitlab creates a different kind of pipeline
<alatiera> will play with it in a couple hours
<bentiss> -> see: the pipeline I triggered is not tagged as "fork"
<bentiss> though I have superpowers, so maybe this is biased
<__tim> I guess 'triggered' here means 'run a new pipeline' and not 'trigger a manual pipeline/job that was created by the user'?
<bentiss> __tim: yeah. in the MR panel: switch tab to pipelines -> run pipeline
<emersion> bentiss: hm so what does that mean for personal projects?
<alatiera> yea i think that's due to your superpowers
agd5f_ has quit [Ping timeout: 480 seconds]
<emersion> i have libdisplay-info in my user namespace and i'm unsure what to do
<alatiera> cause in the gst one I linked above neither the pipeline I or marge triggered were parent-pipelines but still fork pipelines
<bentiss> emersion: either add yourself as a VIP, either request a group or move the project under a group
agd5f_ has joined #freedesktop
<emersion> how do i do the former, for instance?
<emersion> oh there is a list…
ybogdano is now known as Guest7714
* bentiss really wonders why he does this kind of stupid things just at the end of the day, and not on a brancd new day :/
ybogdano has joined #freedesktop
agd5f has quit [Ping timeout: 480 seconds]
Leopold___ has joined #freedesktop
agd5f has joined #freedesktop
Leopold has quit [Ping timeout: 480 seconds]
agd5f_ has quit [Ping timeout: 480 seconds]
agd5f_ has joined #freedesktop
agd5f has quit [Ping timeout: 480 seconds]
<bentiss> kusma: looks like it worked for mesa-demos
<kusma> bentiss: Yep, worked fine! Thanks for the help!
agd5f has joined #freedesktop
<bentiss> kusma: no worries
<alanc> so does this mean I have to add the 4 lines from the to each of the 249 xorg/**/.gitlab-ci.yml files to have CI run on merge requests? or is there a ci-templates rev I can bump them to use to do that for me?
<bentiss> alanc: no ci-templates rev, no. we can work on one if we need. But given the state of xorg, wouldn't it be wiser to just do the lzy approach and request submitters to do that for you?
agd5f_ has quit [Ping timeout: 480 seconds]
agd5f_ has joined #freedesktop
ybogdano has quit [Ping timeout: 480 seconds]
<bentiss> alanc: to add a little bit of context, initially the plan was to give a heads up to people for a month or so. But given the kind of person we have in front of us, we couldn't afford this luxury
agd5f has quit [Ping timeout: 480 seconds]
<alanc> request submitters modify the .gitlab-ci.yml as part of their MRs?
<bentiss> yeah, or submit another one
<alanc> given the status of Xorg, I'd probably update the configs in the handful of projects that get MR's from people who aren't me, and then just put me in the exception list for the rest
agd5f has joined #freedesktop
<bentiss> alanc: works too
<alanc> and yeah, I understand why you did this and have no complaints, just making sure I understand what's needed now
<bentiss> alanc: thanks. Glad to hear that. Honestly
<alanc> heh, looking at I have only personally submitted 1/3 of the MR's in the xorg group over the years (it's what happens when you make the same changes across 249 repos)
agd5f_ has quit [Ping timeout: 480 seconds]
<bentiss> yeah, Xorg is definitely not the cool kid anymore :)
agd5f_ has joined #freedesktop
jarthur has joined #freedesktop
<alanc> and xserver (which includes XWayland) is itself a bit over 1/3 of the MR's across all the xorg projects
<alanc> so for now, that, libX11, and a few others should be enough to cover most MR's we get
agd5f has quit [Ping timeout: 480 seconds]
agd5f has joined #freedesktop
<bentiss> that's weird, Andoni is a developer and it's running in the fork
ylatuya[m] has joined #freedesktop
<ylatuya[m]> Hi! I am trying to start a job ( on a MR to cerbero, an official project ( I understand this is something that should still be possible after right?
<bentiss> __tim: would you mind hitting the "run pipeline" button on
<bentiss> ylatuya[m]: yes, I am currently trying to understand why this is not working
agd5f_ has quit [Ping timeout: 480 seconds]
<ylatuya[m]> Ok, thanks, no worries :) I wasn't sure about how far the restriction was going.
alyssa has joined #freedesktop
<alyssa> bentiss: Just to clarify, with the new rules, do MRs against forks of projects in official project namespaces get CI?
<alyssa> asahi/mesa, nouveau/mesa, etc
<alyssa> I think they do but I'm not super clear on the gitlab details
<bentiss> alyssa: they are supposed to have CI yes. But of course we have hiccups
<alyssa> sounds good
<alyssa> thank you for your tireless work
<alyssa> or tired work
<bentiss> tiring :)
<alyssa> i don't know how tire you have
<alyssa> tiring
<alyssa> got it
<alyssa> thank you for your tiring work
<bentiss> been a ride since last Sunday, yes
<bentiss> but daniels is also someone to thank for
<alyssa> thank you daniels too then :)
<ylatuya[m]> thank you both bentiss and daniels 👍️
<alyssa> bentiss: i kinda hate suggesting this but maybe it would make sense for starting CI to be whitelist only
agd5f_ has joined #freedesktop
<alyssa> i.e. any random can open an MR but if they haven't been permissioned yet they can't trigger a manual pipeline
<bentiss> alyssa: the problem with that list is that it's public, and some will complain
<bentiss> thus the opt-in
<alyssa> i don't really understand the problem
<bentiss> I wouldn't mind having 300 vips
<alyssa> if you want the username of everybody active on fd.o gitlab that doesn't seem hard to scrape with the apis
<bentiss> alyssa: the hook I introduced in the runners have no special privileges, they just fetch unauthenticated data to our gitlab server
<alyssa> no, I understand that, I don't understand why people would complain
<alyssa> I mean I believe oyu
<bentiss> so the list of users needs to be publicly accessible
<alyssa> *you
<bentiss> yes, but we had some
<bentiss> IIRC
<alyssa> wild
<alyssa> contributing to an upstream project inherently reveals your username (which might be a pseudonym for all we care)
<bentiss> yep, agree
<alyssa> I mean
<bentiss> ylatuya[m]: I *think* this is because the wrokflow rules are different to what I set in the issue with the announce
<alyssa> the nuclear option is to require an invite to join fd.o gitlab at all -- and if not for the bug trackers i might even be tempted -- but that seems really bad for not biting newcomers
agd5f has quit [Ping timeout: 480 seconds]
<bentiss> yes. WE already had that discussion
<bentiss> we
<alyssa> Weeeeeeee
<alyssa> (I might have even been party to that discussion. Brain is a little slow right now :p)
<bentiss> ylatuya[m]: would you mind rebasing on top of main your MR, if possible and change the .gitlab-ci.yaml with the workflow block at
<bentiss> To see if that changes something
<ylatuya[m]> bentiss: sure, let me try
agd5f_ has quit [Ping timeout: 480 seconds]
<eric_engestrom> just catching up with #freedesktop; for the "no signups except by invite" thing gitlab has a bug (that they literally call a feature, well a *missing* feature) where it will send invites even if signups are closed, but users get an error when accepting these invites
<eric_engestrom> alyssa: ^
<alyssa> delight
<ylatuya[m]> bentiss: should I override existing ones or append the 2 new ones?
<eric_engestrom> as for what's going on, should we add this pre_clone_script hook to our runners as well?
<bentiss> ylatuya[m]: I would overwrite it entirely for starter
<bentiss> eric_engestrom: it's up to you, but this way we can change the whole config from a single push to a repo, with is kind of nice I would say
<eric_engestrom> ok
<eric_engestrom> and also, those of us who run extended pipelines on our forks to compensate for partial coverage in merge pipelines, do we need to add ourselves to that allow-list, or can we still do that?
<bentiss> I would suggest to add yourself in the list
<bentiss> anything not in a group is not permitted
<ylatuya[m]> bentiss: it failed as well ->
<bentiss> or we can have a "ci-runner-permitted" group where most people add projects (after a review). The gnome folks have a "World" group for that
<alyssa> oh, also to be clear -- clicking the little gears under an open MR to an official project still triggers CI? it's not just Marge pipelines?
<alyssa> (sometimes I like to do a partial run on an MR before assigning to marge because once I put my MR in the queue I'm emotionally invested in seeing it merged :~P)
<bentiss> alyssa: if you add yourself to the allow-list, you'll be allowed to do it. If not, then not
<bentiss> well, no, l;et me correct that
<eric_engestrom> sounds like all the regular contributors need to be on that list then?
<bentiss> eric_engestrom: that would be easier, this way your don't have to deal with the pain of the MR pipelines
<bentiss> alyssa: so... on mesa, it would work: -> the MR runs in the namespace of the project
<alyssa> sounds good
<bentiss> alyssa: on gst/cerbero -> it doesn't. There is a little "fork" which blocks the script
<bentiss> why is that project different, I have strictly no idea ATM
<alyssa> sounds like you're having fun /s
<bentiss> you have no idea...
<bentiss> and I wanted to do some sports, but I have to leave in a few minutes, so painful
<mupuf> bentiss: you have my permission to go
<mupuf> ;)
<mupuf> I would kick your butt to go, but I'm too far for that
ximion has joined #freedesktop
<jenatali> It'd be nice if someone took a first stab at building a list of well-known/trusted folks for CI, rather than asking everyone to individually contribute their own names?
<daniels> alyssa: please use ci_run_n_monitor with a regex filter rather than the web trigger, so it only runs the targeted leaf jobs rather than everything
<eric_engestrom> +1, and I think this should be done before closing the gate
<eric_engestrom> (replying to jenatali)
<alyssa> daniels: I don't know what that is. Could you point me to docs?
<alyssa> I assume this lets me just run panfrost jobs?
<daniels> bentiss: can we have a ci-ok group which has all of our top-level groups added as members? so if you have access to any ‘real’ project then you have access to CI
<eric_engestrom> alyssa: I don't think we have any docs for it 🙃
<anholt> ~/src/mesa/.gitlab-ci/bin/ --target <regex> to run whatever is necessary, and no more, for the job regex.
<bentiss> daniels: but can we publicly request the list of members of that group?
<daniels> alyssa: what anholt said :)
<anholt> --stress is also super useful for your overnight "is my job actually stable" runs
<alyssa> sounds good, will give that a try
<eric_engestrom> daniels: I like this idea of meta group
<alyssa> that seems a lot more convenient than trying to click both arm_build and x86_build given that the UI is racey lol
<daniels> bentiss: no but you can set group membership to include another group. so we can set that group to include all mesa/wayland/gst/… members, and then is_member(mesa_user, ci_ok_group) will be true
<daniels> alyssa: yeah it’s way better, and also CLI rather than web
<alyssa> I do like that yes
<daniels> (sorry am on phone so limited throughout)
<bentiss> daniels: curl -L | jq -> unauthorized
<daniels> bentiss: can we give it the API token of a user with no perms to do that?
<bentiss> not sure
<bentiss> daniels: maybe it works
<bentiss> at least it works with my "work" account that is not affiliated to any group
<bentiss> should I switch the script off for the night?
<bentiss> (the european night)
<bentiss> daniels, mupuf, emersion, alanc, __tim, eric_engestrom ^^
<eric_engestrom> bentiss: yeah I think it's best to turn it off until it's no longer disruptive to most legitimate users
<bentiss> k
<bentiss> and done
<bentiss> ylatuya[m]: you should be good now, it's disabled for now :)
<bentiss> now that I wont take thunder from anyone because it is back to the previous situation, I'm off for the day
<eric_engestrom> haha
<eric_engestrom> 👋
<dcbaker> I know CI is crazy right now, but are we expecting the venus-lavapipe jobs to timeout due to not finding a runner
<ylatuya[m]> bentiss: It's working now, thanks!
<anholt> dcbaker: they're disabled in main, yes.
<eric_engestrom> and hopefully the meta-group idea is usable, and we can turn it back on soon :)
<anholt> er, I guess my MR did land, so they're back on on the general shared runner pool
<dcbaker> this is what I'm seeing on the staging/23.0 branch:
MajorBiscuit has quit [Quit: WeeChat 3.6]
<dcbaker> And sorry for adding more CI questions :/
<dcbaker> oh, I think I see
<dcbaker> your patch isn't a straight revert, I'll pull that and see if it fixes my issue
<dcbaker> anholt: thanks!
<daniels> bentiss: thanks, g’night!
<alyssa> ok, trying this newfangled script
<alyssa> "⏲ for the pipeline to appear"
<eric_engestrom> bentiss: just to save you a bit of reading, you'll want `/all` to include transitive users (ie. all of them in a meta-group), and you can filter by user_id to avoid pulling everything and then having to filter yourself; end result is:
<alyssa> let's try with --force-manual
<DavidHeidelberg[m]> alyssa: did you made a `git push`? :D
<alyssa> Yes
<eric_engestrom> alyssa: this means there's no pipeline in your fork for the commit that's currently you HEAD (or --rev)
<DavidHeidelberg[m]> waiting for pipeline usually appears when pipeline is not there or you push just changes in the commit message (not the code)
<eric_engestrom> you can open to verify yourself
<alyssa> in the gitlab UI it says
<alyssa> Merge request pipeline #829678 waiting for manual action for 8e6d47e7
<alyssa> which is my HEAD
<alyssa> that's a mesa/mesa pipeline not an alyssa/mesa one
<alyssa> because it's in MR context
<alyssa> I guess
<eric_engestrom> I don't think that's supported
<eric_engestrom> it always looks in your fork
<eric_engestrom> iirc
<alyssa> that sounds like a bug if the pipelines can end up in mesa/mesa?
<alyssa> oh there it goes
<alyssa> it just took a few minutes
<eric_engestrom> yeah imo it should be possible to pass --pipeline instead of --rev and letting the script guess where the pipeline is
<alyssa> I mean I like the script guessing as long as it guesses right ;)
<eric_engestrom> I tried to hook that up but failed
<alyssa> so if ctrl-c out of the job it'll keep going I assume?
<alyssa> hmm. I wonder why G52 in CI is slower than the G52 on my desk
rsjw has joined #freedesktop
<rsjw> can I get fork permission on gitlab? the username is the same as here
<mupuf> alyssa: I have been experiencing the same on my desktop PC vs in CI. These issues are annoying to review
<eric_engestrom> alyssa: yeah, ^C will stop the script, but doing that doesn't auto-cancel the job(s)
BlkPoohba has joined #freedesktop
alanc has quit [Remote host closed the connection]
___nick___ has joined #freedesktop
alanc has joined #freedesktop
agd5f has joined #freedesktop
mvlad has quit [Remote host closed the connection]
___nick___ has quit []
___nick___ has joined #freedesktop
___nick___ has quit []
___nick___ has joined #freedesktop
i-garrison has quit [Read error: Connection reset by peer]
pendingchaos has quit [Ping timeout: 480 seconds]
i-garrison has joined #freedesktop
pendingchaos has joined #freedesktop
Kayden has quit [Ping timeout: 480 seconds]
Kayden has joined #freedesktop
Haaninjo has joined #freedesktop
danvet has quit [Ping timeout: 480 seconds]
<bentiss> rsjw: please open a bug at by following the template. We need to get a trace on who asked what, we have been abused not later than last week
ybogdano has joined #freedesktop
ybogdano is now known as Guest7728
Guest7714 is now known as ybogdano
alyssa has left #freedesktop [#freedesktop]
vkareh has quit [Quit: WeeChat 3.6]
pixelcluster_ has joined #freedesktop
pixelcluster has quit [Ping timeout: 480 seconds]
pixelcluster_ has quit []
pixelcluster has joined #freedesktop
___nick___ has quit [Ping timeout: 480 seconds]
Guest7728 has quit [Ping timeout: 480 seconds]
trinitronx has joined #freedesktop
trinitronx has quit [Quit: leaving]
trinitronx has joined #freedesktop
MrCooper_ has joined #freedesktop
MrCooper has quit [Ping timeout: 480 seconds]
MrCooper_ has quit [Remote host closed the connection]
<anholt> hmm, cluster of jobs that all took an hour and timed out on this runner
<anholt> (across projects)
MrCooper has joined #freedesktop
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #freedesktop