07:36 <bentiss> \o/ container registry is now hosted at hetzner and fastly :)

07:37 <bentiss> AFAICT, we don't have anything else running at Equinix, except for the artifact data of the past 4 years that we can probably drop (haven't had a single request, well, one was "that's fine)

07:37 <bentiss> heh, the registry UI is much faster now as well

07:38 <bentiss> now I have one gitlab upgrade to attend as well

07:44 <eric_engestrom> bentiss: congrats!

07:44 <eric_engestrom> did you also drop the packet.net runner?

07:44 <eric_engestrom> https://gitlab.freedesktop.org/mesa/mesa/-/jobs/73582702

07:44 <bentiss> oh, yes, that tag got dropped

07:45 <bentiss> I can re-add it in the admin UI if needed

07:45 <bentiss> eric_engestrom: done

07:45 <bentiss> but it would be nice to drop the tag in mesa, yeah

07:46 <eric_engestrom> does we actually need any tag for that job?

07:46 <eric_engestrom> i feel like it was a bandwidth optimisation thing, not a functionality thing, right?

07:48 <bentiss> yes, exactly. It was at the time when the gstreamer runner accepted the untagged jobs and we had a slightly different config

07:48 <bentiss> I think this is fine now

07:49 <eric_engestrom> "this is fine" -> to not have a tag, right?

07:50 <eric_engestrom> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34271 to drop it

08:02 <bentiss> eric_engestrom: yep, sorry I should have been clearer

08:03 <bentiss> and looking at your change, indeed, it was just a network optimisation

08:22 <bentiss> now that this is done, gitlab is about to be upgraded to 17.10.1

08:29 <bentiss> and this is done too as well

12:06 <mupuf> bentiss: you are on fire!

12:07 <mupuf> and congrats to eric_engestrom and yourself for deploying job prioritization :o

12:07 <mupuf> now, we just need to make the DUTs do the same and we'll be in a much better state!

13:25 <daniels> just bm and the non-Deck b2c ones left right?

13:26 <eric_engestrom> yep, and the deck ones are a hack, not a full solution

13:26 <eric_engestrom> for bm I'm not sure if we really want to invest time working on that

13:38 <eric_engestrom> the igalia bm farm will go away Really Soon Now™, and then it's just the google-freedreno farm that's left (I have no idea what robclark's plans are, whether to keep it, migrate to ci-tron or lava, or something else), but it might not be worth the effort, unless there's an easy solution someone has already thought about

13:55 <daniels> yeah, clearly the solution to bm being suboptimal is no bm :)

14:02 <daniels> eric_engestrom: whilst you're here, it would be awesome to get ci-tron emitting https://mesa.pages.freedesktop.org/-/mesa/-/jobs/73586938/artifacts/results/lava_job_detail.json so we can track runtimes in https://ci-stats-grafana.freedesktop.org/d/edz36awvzcgzka/dut-time-per-gitlab-job?orgId=1

15:19 <daniels> hngh, I really wish we could use variables in timeouts

15:44 <eric_engestrom> (I'm with family this weekend so I have very random moments of free time)

15:45 <eric_engestrom> for variables in timeouts, I definitely agree; have a look at the workaround I did for the builds: https://gitlab.freedesktop.org/mesa/mesa/-/commit/6425b6e3d4a29ae6a5b47864c68deb5723dfe6df

15:46 <eric_engestrom> for the logs of the parts of the job, we could probably do this, I'll put that on my list

16:01 <daniels> yeah, I was going through adding timeouts to jobs, but I can only do that for pure-software stuff

16:01 <daniels> I guess b2c could do it as well

17:00 <eric_engestrom> "adding timeouts to jobs" you mean all the jobs that just inherit the default 1h instead of setting one? thanks, that was something I wanted to do for a while! I was thinking that once that's done, we could set a default timeout to eg. 1sec, so that no job can ever accidentally have 1h timeout

17:39 <daniels> oh, good idea!

17:43 <daniels> here's what I've got in my branch atm https://hst.sh/eperusixuq.less

17:45 <daniels> I can add one to all the container jobs, but the LAVA ones, mm ... again we want very different timeouts between pre-merge and post-merge, so I'm not sure if we should just specify a massive timeout in the common lava rules?

18:01 <eric_engestrom> daniels: you can use the same trick yeah, the biggest timeout in `timeout:` and the real one in software

18:03 <eric_engestrom> for your link, "(project)" is a very useful info, to know which jobs aren't setting it yet

21:34 <karolherbst> bentiss: is fastly only used aas a CDN or can it also do bot/scrapper protection on gitlab itself? (e.g. preventing massive load through git blame pages or something)