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
busheling has left #freedesktop [Leaving]
Leopold_ has quit [Remote host closed the connection]
Guest6707 has quit [Read error: Connection reset by peer]
<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>
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
<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!
<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>
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
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?
<kusma>
The text says "What it means for me, a maintainer of a project part of gitlab.freedesktop.org? 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
<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
<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
<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)
<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
<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>
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/ci_run_n_monitor.py --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)
<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: