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
MrCooper_ has joined #freedesktop
MrCooper has quit [Ping timeout: 480 seconds]
<whot> maybe I missed something in the backlog, but is the script supposed to be enforcing? because right now it isnt
<__tim> I think it was disabled again for the night
<whot> ah, ok, thanks
<whot> *facepalm* it's in a git repo, I can just look up the commits. and yes, it got re-disabled on purpose
Haaninjo has quit [Quit: Ex-Chat]
Haaninjo has joined #freedesktop
MrCooper has joined #freedesktop
co1umbarius has joined #freedesktop
MrCooper_ has quit [Ping timeout: 480 seconds]
columbarius has quit [Ping timeout: 480 seconds]
co1umbarius has quit [Remote host closed the connection]
co1umbarius has joined #freedesktop
<Venemo> how can I check the queue of MRs that the marge bot currently has?
chipxxx has joined #freedesktop
jarthur has quit [Ping timeout: 480 seconds]
jarthur has joined #freedesktop
Leopold__ has joined #freedesktop
Leopold___ has quit [Ping timeout: 480 seconds]
snuckls_ has joined #freedesktop
miracolix has quit [Ping timeout: 480 seconds]
ximion has quit [Quit: Detached from the Matrix]
BlkPoohba has quit []
rsjw has quit [Quit: rsjw]
Leopold__ has quit [Remote host closed the connection]
Leopold_ has joined #freedesktop
<Venemo> thx
<Venemo> what is the problem here? the ci appears all green but the bot refuses to merge
<bentiss> anholt: yep, looks like that guy came back
<bentiss> or it's simply dead. I can't even reboot it from the equinix console
<bentiss> mupuf: that guy "First Name Last Name", it's the one who asked here credentials yesterday "rsjw". I asked him/her to specifically use the template, so I won't bother with him and just let him go away
<mupuf> bentiss: I see
<mupuf> indeed, the guy went out of his way to remove the issue
<bentiss> mupuf: but at least we don't appear to be the bad guys here with your answer. So...
<bentiss> well, m3l-16 is dead I think. It doesn't even respond to reboot or rescue from the equinix console. I'll just respawn a new one (and test my cloud-init modifications)
dcbaker has quit [Quit: Bridge terminating on SIGTERM]
Wallbraker has quit [Quit: Bridge terminating on SIGTERM]
gkiagia has quit [Quit: Bridge terminating on SIGTERM]
DavidHeidelberg[m] has quit [Quit: Bridge terminating on SIGTERM]
twopubsolar[m] has quit [Quit: Bridge terminating on SIGTERM]
nirbheek has quit [Quit: Bridge terminating on SIGTERM]
bstrie[m] has quit [Quit: Bridge terminating on SIGTERM]
bendlas[m] has quit [Quit: Bridge terminating on SIGTERM]
ewlsh[m] has quit [Quit: Bridge terminating on SIGTERM]
muhlinux[m] has quit [Quit: Bridge terminating on SIGTERM]
razze[m] has quit [Quit: Bridge terminating on SIGTERM]
gnfzdz[m] has quit [Quit: Bridge terminating on SIGTERM]
aenderboy[m] has quit [Quit: Bridge terminating on SIGTERM]
tintou has quit [Quit: Bridge terminating on SIGTERM]
Trevinho has quit []
swick[m] has quit [Quit: Bridge terminating on SIGTERM]
tinywrkb has quit [Quit: Bridge terminating on SIGTERM]
pitsch[m] has quit []
ylatuya[m] has quit [Quit: Bridge terminating on SIGTERM]
dylan-m[m] has quit [Quit: Bridge terminating on SIGTERM]
cassidy[m] has quit [Quit: Bridge terminating on SIGTERM]
pv has quit []
jenatali has quit [Quit: Bridge terminating on SIGTERM]
mitTengiz[m] has quit []
ttancos[m] has quit []
heftig has quit [Quit: Bridge terminating on SIGTERM]
marcel203s[m] has quit [Quit: Bridge terminating on SIGTERM]
scorpion2185[m]1 has quit []
nielsdg has quit [Quit: Bridge terminating on SIGTERM]
unrznbl[m] has quit [Quit: Bridge terminating on SIGTERM]
Soroush has quit [Quit: Bridge terminating on SIGTERM]
inpursuitofsilence[m] has quit [Quit: Bridge terminating on SIGTERM]
alatiera_afk[m] has quit [Quit: Bridge terminating on SIGTERM]
therickestrick001[m] has quit []
sergi has quit [Quit: Bridge terminating on SIGTERM]
Hazematman has quit [Quit: Bridge terminating on SIGTERM]
sewn has quit [Quit: Bridge terminating on SIGTERM]
tomeu has quit [Quit: Bridge terminating on SIGTERM]
dabrain34[m] has quit [Write error: connection closed]
zeenix[m] has quit [Write error: connection closed]
nazarewk[m] has quit [Write error: connection closed]
chrysn[m]1 has quit [Write error: connection closed]
gallo[m] has quit [Write error: connection closed]
siddh has quit [Write error: connection closed]
halfline[m] has quit [Write error: connection closed]
kusma has quit [Write error: connection closed]
m5zs7k_ has quit [Max SendQ exceeded]
Mark[m]1 has quit [Write error: connection closed]
m5zs7k has joined #freedesktop
Nova[m] has quit []
<daniels> Venemo: a618-vk took a long time to eventually fail hard; it was retried but that was too late - look at the slowdown in the log beginning here before it stops completely
M0xMRTT[m] has joined #freedesktop
msizanoen[m] has joined #freedesktop
ximion has joined #freedesktop
chipxxx has quit [Ping timeout: 480 seconds]
chipxxx has joined #freedesktop
<bentiss> \o/ the generate-cloud-init script is working fine. I did not mess up yesterday :)
<ofourdan> quick question, I asked i none of the MR, but I gues I might as well ask here - The gitlab-ci chnage to enable detached MR pipelines, we need to cherry pick the change in all ctable branches as well, otherwise the backport MRs will have their CI fail, right?
<ofourdan> (sorry too many typos!)
chipxxx has quit [Remote host closed the connection]
chipxxx has joined #freedesktop
<MrCooper> ofourdan: presumably, yes
<bentiss> ofourdan: yes, but it was slightly too disruptive, so I am looking into another solution.
<ofourdan> so I shouldn't fiel the backport MR?
<bentiss> ofourdan: conceptually the same (a script will allow or not), but maybe more robust
<bentiss> ofourdan: please hold for a day
<ofourdan> alright
<ofourdan> just to be crystal clear, should I hold on just for the stable branches, or do you mean you're working on another solution for all the branches (so we should not apply the change from
<bentiss> ofourdan: still foggy, so I can't really tell you a definite answer
<bentiss> basically, we have 2 options: one is register all legit users in a special group, all legit users mean all of those who are in an actual project as reporter at least
<bentiss> the other is to better detect MR through environment variables and allow them there
<MrCooper> the latter would still allow abuse via MRs, wouldn't it?
<bentiss> MrCooper: yes and no. It depoends on the implementation and the restrictions we put in place :)
<bentiss> MrCooper: TBH, I already know that there is a gigantic hole in that process. But I won't tell it ther, just because I do not want to have people just cherry-picking the solution
<bentiss> so... what is interesting, is that with the CI_JOB_TOKEN, I can retrieve the information, which has a lot of interesting things ;)
danvet has joined #freedesktop
gallo7753 has quit [Remote host closed the connection]
gallo7753 has joined #freedesktop
ximion has quit [Quit: Detached from the Matrix]
agd5f_ has joined #freedesktop
kbingham has quit [Ping timeout: 480 seconds]
agd5f has quit [Ping timeout: 480 seconds]
mvlad has joined #freedesktop
MajorBiscuit has joined #freedesktop
agd5f has joined #freedesktop
agd5f_ has quit [Ping timeout: 480 seconds]
strk has joined #freedesktop
<strk> hello there, thanks for what you guys are doing with the free desktops !!
<strk> I've a question about icons... how do I tell which directories are scanned for icons ?
<strk> I'm using an application which doesn't seem to recognize the name of an icon but I have it in many places:
AbleBacon has quit [Read error: Connection reset by peer]
<eric_engestrom> strk: see /topic, this channel is about the infrastructure on
<eric_engestrom> strk: I don't know where you should go to ask about icons though; good luck :)
<ofourdan> maybe on the xdg mailing list (<>)?
<strk> is there no xdg room that you know ?
<strk> (chat room)
<ofourdan> or maybe try to get in touch the the app devs of that particular application which fails to load the icon?
vbenes has quit [Remote host closed the connection]
Haaninjo has quit [Quit: Ex-Chat]
<bentiss> Finally! Well, it's not a solution, but I managed to understand why gstreamer projects are different than mesa in respect to the merge pipelines:
<bentiss> -> to be able to *not* run in the fork you need to had permissions to run CI in the parent
dabrain34[m] has joined #freedesktop
<dabrain34[m]> hey I havent changed anything on my personal project and CI seems to work as before, is it expected ?
<bentiss> and -> developers/maintainers can run CI only if they are "allowed to merge or push to the protected branch.
<bentiss> but on gstreamer, developers/maintainers can not push on protected branches, only marge can...
<bentiss> dabrain34[m]: yes, it's normal, it is temporary disabled, too disruptive for regular projects
<dabrain34[m]> ok
<dabrain34[m]> but i'm not sure if I should add the snippet: workflow: rules: - if: $CI_PIPELINE_SOURCE == 'merge_request_event' - if: $CI_PIPELINE_SOURCE == 'push' to my project then
<bentiss> dabrain34[m]: for now, it's not necessary, I'm still trying to understand if I can do something better
<bentiss> dabrain34[m]: so hold on a little
<dabrain34[m]> ok thanks for confirming
<bentiss> please :)
<mupuf> bentiss: right!
<mupuf> good find!
<bentiss> mupuf: so after testing, it turns out that gstreamer also protects '*' which is the problem
<mupuf> well, the fix would be easy then: remove * from the protected branches and use social rules to enforce not creating branches there
<bentiss> mupuf (or anyone else, really): can I borrow a little bit of your time and prepare a project based on which would build both curl *and* jq for aarch64 and x86_64
<bentiss> mupuf: yes, or change the regex to something that doesn't break this
<bentiss> regarding jq, I can officially download for x86, but not arm. And if I have this I can protect the script against kiddies overwriting the variables
<mupuf> bentiss: sure
<mupuf> let me create a pipeline in the bot repo
<bentiss> mupuf: thanks!
Trevinho[m] has joined #freedesktop
Wallbraker has joined #freedesktop
alatiera_afk[m] has joined #freedesktop
aenderboy[m] has joined #freedesktop
anomalous_creator[m] has joined #freedesktop
bendlas[m] has joined #freedesktop
bstrie[m] has joined #freedesktop
cassidy[m] has joined #freedesktop
chrysn[m]1 has joined #freedesktop
cmeissl[m] has joined #freedesktop
dabrain34[m]1 has joined #freedesktop
dcbaker has joined #freedesktop
dylan-m[m] has joined #freedesktop
ewlsh[m] has joined #freedesktop
gallo[m] has joined #freedesktop
gkiagia has joined #freedesktop
gnfzdz[m] has joined #freedesktop
halfline[m] has joined #freedesktop
hasebastian[m] has joined #freedesktop
Hazematman has joined #freedesktop
heftig has joined #freedesktop
inpursuitofsilence[m] has joined #freedesktop
jenatali has joined #freedesktop
jjardon[m] has joined #freedesktop
kusma has joined #freedesktop
mairacanal[m] has joined #freedesktop
marcel203s[m] has joined #freedesktop
Mark[m] has joined #freedesktop
muhlinux[m] has joined #freedesktop
nazarewk[m] has joined #freedesktop
nielsdg has joined #freedesktop
nirbheek_ has joined #freedesktop
DavidHeidelberg[m] has joined #freedesktop
pitsch[m] has joined #freedesktop
pv has joined #freedesktop
razze[m] has joined #freedesktop
scorpion2185[m]1 has joined #freedesktop
sewn has joined #freedesktop
siddh has joined #freedesktop
sergi has joined #freedesktop
Sumera[m] has joined #freedesktop
swick[m] has joined #freedesktop
Nova[m] has joined #freedesktop
therickestrick001[m] has joined #freedesktop
tintou has joined #freedesktop
tinywrkb has joined #freedesktop
underpantsgnome[m] has joined #freedesktop
tomeu has joined #freedesktop
ttancos[m] has joined #freedesktop
twopubsolar[m] has joined #freedesktop
mitTengiz[m] has joined #freedesktop
Soroush has joined #freedesktop
unrznbl[m] has joined #freedesktop
MatrixTravelerbot[m]1 has joined #freedesktop
ylatuya[m] has joined #freedesktop
zeenix[m] has joined #freedesktop
zredshift[m] has joined #freedesktop
miracolix has joined #freedesktop
<bentiss> Alright. Once I get jq for aarch64, I'll be able to iron out the gating script (without changing the protected branch settings): using the job token I can retrieve reliable data like commit, type of pipeline, and then I'll be able to check that the CI_MERGE_REQUEST_PROJECT_ID variable has not been tempered with, by checking if the job's commit is present in the target tree...
snuckls_ has quit [Ping timeout: 480 seconds]
<mupuf> bentiss: do we have a local copy of alpine:latest?
<mupuf> or a proxy to
bionade24 has quit [Remote host closed the connection]
bionade24 has joined #freedesktop
vkareh has joined #freedesktop
<mupuf> <-- this is where the generated binaries will land when merging
<mupuf> (I cheated and already uploaded them)
DodoGTA has quit [Quit: DodoGTA]
DodoGTA has joined #freedesktop
DodoGTA has left #freedesktop [#freedesktop]
hadess has joined #freedesktop
<hadess> hey
<bentiss> mupuf: thanks! (sorry I was having lunch)
<hadess> could anyone please double-check whether i need to do anything else to implement the CI changes?
<hadess> i have about 10 more repos to go after that, wanted to be sure that was enough
<hadess> or i could have looked at the other commits that referenced the same issue and found that it was enough indeed
<hadess> n/m ;)
<bentiss> hadess: yep, looks good. I'll probably enforce the policy later today. You can check at the beginning of your logs if this is enough
MrCooper has quit [Ping timeout: 480 seconds]
<hadess> is that the "Thank you for contributing to" message, right?
<bentiss> yep. Otherwise you get a blob telling you don't have enough privileges
<hadess> tip-top, thanks
<mupuf> bentiss: no problems!
DodoGTA has joined #freedesktop
BlkPoohba has joined #freedesktop
<bentiss> hadess: already merged
<hadess> 😱️
<hadess> that was quick
<hadess> bentiss: thanks :)
<bentiss> heh, no worries
<bentiss> there is no reasons to delay that kind of addition when we know the person
Leopold_ has quit [Remote host closed the connection]
<mupuf> bentiss: can I remove the duplicate packages?
Leopold_ has joined #freedesktop
<mupuf> or did you already start using them?
<bentiss> mupuf: many thanks!
<bentiss> no, I haven't pulled them
<bentiss> but even if it's going to be a one off, everytime we respin a runner, so we can safely kill them at will
<mupuf> excellent
<bentiss> mupuf: just FYI, now, all jobs will have an available curl/jq at /host/bin, in case you hate wget ;)
<mupuf> lol
<mupuf> I would rather not depend on anything coming from the runner's host ;)
<bentiss> heh :)
<mupuf> crossing fingers that jq will work nicely
<mupuf> it doesn't pass its test suite when when built statically
<bentiss> should be easy enough to test
<bentiss> oh...
* mupuf added a simple test as part of the build process
<bentiss> well, I am not doing a lot of fancy stuff with it, just fetching fields in json
<mupuf> yeah, exactly, shoud be fine
<jenatali> bentiss: alatiera: Are you planning to apply this policy to the Windows runners too?
<mupuf> I used the commands they recommend for building static binaries
<bentiss> jenatali: I don't have any sort of control over the windows runners, so it's up to you and Collabora to enforce it I guess
<jenatali> Ack. So it's up to Collabora then I guess
* mupuf hopes the static binary jobs won't get built every single time an MR comes to this repo
mohamexiety has joined #freedesktop
<bentiss> mupuf: it's deployed on all runners I control. Now I'm trying to implement the new script
<mupuf> yeepee!
<alatiera> windows is more fucked up, cause one of the runners is a shell executor
<bentiss> alatiera: would it make sense to register the windows runners only in the few project they are required?
<bentiss> like gstreamer and mesa?
alpernebbi has quit [Ping timeout: 480 seconds]
<alatiera> I think so
<alatiera> although with the pre-clone hook we might be good
<alatiera> but I haven't managed to get around it yet
<ndufresne> Won't that break pre-merge CI all over the place ? "Starting 2023-03-14, or before if we see a spike in the attacks, only pipelines running in a known, official project will be run on the shared runners we manage at Jobs for projects in personal namespaces will not be able to leverage shared runners."
<ndufresne> ah, I think its the working that is very confusing
<ndufresne> So if the CI is part of a Merge request (that everyone see) it will run for everyone ?
<ndufresne> * the wording)
<bentiss> ndufresne: that's the plan yes
<bentiss> ndufresne: yesterday it broke pre-merge for gstreamer, and I found out why today, so making more tests
<ndufresne> ah, that's the thing that update the docs I suppose
<ndufresne> made a patch to add myself, but when I came to write the commit, I didn't figure-out why I'd need to be an exception, maybe I'll abstain ...
<ndufresne> (specially that I usually use a private runner when I want to mess around CI script without affecting anyone)
MrCooper has joined #freedesktop
<bentiss> ndufresne: honestly, there are no reasons for not adding yourself to the list, and that's the pain point: because of a handlful of persons, we have to put restrictions on anybody :(
<ndufresne> its not like we didn't know this would ever happen, from day one we knew it was easy to use the runners for non-coding related tasks, so I'm not upset, glad we could avoid it for so long of course
<ndufresne> its just illustrate how the majority of the crypto users are anarchist that don't care about others
<bentiss> yeah. It's actually surprising we had such a long ride without much trouble TBH :)
* alatiera hasn't manage to catch up on the backlog from yday yet 😆
<cassidy[m]> how can I still use shared runners despite not being (yet) in this users list?
<ndufresne> cassidy[m]: just send a MR against
<ndufresne> the exception list is in runner-gating/users.txt
<cassidy[m]> ndufresne: yes I was about to do that but then realize I was still able to use these runners :)
MajorBiscuit has quit [Ping timeout: 480 seconds]
strk has left #freedesktop [WeeChat 3.7.1]
<bentiss> cassidy[m]: right now the policy is not enforced, we are working through the corner cases
<cassidy[m]> ok, thanks :)
alpernebbi has joined #freedesktop
pjakobsson has quit [Remote host closed the connection]
MajorBiscuit has joined #freedesktop
karolherbst_ has joined #freedesktop
karolherbst has quit [Ping timeout: 480 seconds]
agd5f_ has joined #freedesktop
agd5f has quit [Ping timeout: 480 seconds]
<bentiss> mupuf, daniels: I am scratching my head: why my code at (only on ml-13 for now) works most of the time, but some times, when there are new lines characters in the commit description it fails:
<bentiss> basically, it all comes down to:
<bentiss> GATING_JOB=$(curl --header "Authorization: Bearer ${CI_JOB_TOKEN}" ${GITLAB_API}/job)
<bentiss> GATING_USER=$(echo "$GATING_JOB" | jq -r '.user.username')
<bentiss> and the jq call is not happy
* bentiss is missing something obvious for sure
MatrixTravelerbot[m]1 has quit []
scorpion2185[m]1 has quit []
mairacanal[m] has quit []
jjardon[m] has quit [Quit: Client limit exceeded: 20000]
anomalous_creator[m] has quit []
tintou has quit []
systwi has quit [Ping timeout: 480 seconds]
systwi has joined #freedesktop
Trevinho[m] has quit []
dcbaker has quit []
M0xMRTT[m] has quit [Quit: Client limit exceeded: 20000]
<bentiss> arggg, it's because of 'sh', I'm not in bash and the behavior is slightly different
kusma has quit []
underpantsgnome[m] has quit []
siddh has quit []
<bentiss> at least I can reproduce now
DavidHeidelberg[m] has quit []
nielsdg has quit []
sergi has quit []
Soroush has quit []
pv has quit []
ximion has joined #freedesktop
msizanoen[m] has quit []
<Venemo> hi
<Venemo> it seems this person requested a GitLab label and hasn't received any replies in months:
alyssa has joined #freedesktop
<jenatali> Venemo: From that screenshot, only 2 of the 5 issues were WSL-specific... IMO I don't see the point of such a label
<alyssa> bentiss: " 14:17 <bentiss> ndufresne: honestly, there are no reasons for not adding yourself to the list, and that's the pain point: because of a handlful of persons, we have to put restrictions on anybody :( "
<alyssa> I've given this a bit more thought since yesterday
<alyssa> Here's the thing... I can't articulate a single *good* reason to not have a public list of authorized gitlab usernames
<Venemo> jenatali: can you respond to the issue and close?
<alyssa> bentiss: and for every complaint about that list, I hear a dozen complaints about CI not working well
<alyssa> which makes me very much inclined to say we should do the public username allowlist approach anyway, even though somebody somewhere didn't like it for some reason
<alyssa> (If there is an *actual* good reason that someone can articulate on why we absolutely cannot have this list public, then please tell me, either here or in a private message. But I'm really struggling to come up with one.)
ximion has quit [Quit: Detached from the Matrix]
<bentiss> alyssa: Agree :)
<alyssa> bentiss: Great. Who do I need to convince to make this happen then? ;)
<bentiss> but meanwhile we can try to make the CI work as close as possible than previously while that list is set in place
<alyssa> Yeah, obviously it couldn't be effective until N weeks after we decide we're doing it, to get all the names in place
<bentiss> alyssa: how do you envision fomring that list? opt-in like today? or mass import?
<alyssa> Not sure yet.
<Venemo> what is wrong with opt-in?
<alyssa> Venemo: Pain in everyone's ass
<bentiss> just takes time :)
<Venemo> for example, I don't see why I would need my name on that list
<alyssa> Venemo: so you can check CI manually (possibly a subset of jobs) for a draft MR that's not ready to go to merge
<bentiss> what would be nice actually was if every project/group creates an issue to gather the list with a @all, and then submit *one* mr for the entire project
<Venemo> I usually just click on the play button on my MRs, which should be fine right? or I push directly to the valve ci which should also be fine because it's already restricted
<alyssa> Venemo: right, this list is "the list of people authorized to click play buttons on their MRs"
<Venemo> ah
<jenatali> Or more specifically the list of people who can click play before creating a MR
<Venemo> I see...
<jenatali> (If I understand correctly anyway)
<jenatali> As long as you have developer permissions, the MR pipeline that's created should be able to be played. If you don't, a developer will have to create one for you
<alyssa> Venemo: DM'd the reason
<Venemo> got it
<Venemo> so because I have the developer role already, my name doesn't need to be on a list right? or would this be restricted even further?
<alyssa> right, so
<alyssa> bentiss: The easiest answer is a mass import of anyone with develper roles on project namespace projects
<jenatali> The developer role ensures that MR pipelines work. If you want fork pipelines to work (without creating a MR) then you need to be on this list
<alyssa> which I think should get 99% of what we want
<bentiss> Venemo: I can not get the list of the members of a group without authentication, so I need to create a specifc list with the users. So you'll need to be added to that list manually at some point
<Venemo> then I got two suggestions: either put everyone who currently has the developer role to the list, or just see who submitted at least 10 patches in the past 6 months and add them to the list
<alyssa> the former should be straightforwardish with the gitlab api (and authentication)
<bentiss> alyssa: agree, but I don't want to be placed on the spot because I did a mass import of a public list os users, and one of them is not happy that the logs will show it forever
<alyssa> bentiss: great, then send me the list and I'll MR it and take the blame :~P
<alyssa> (am I being facetious? I don't even know myself!)
<bentiss> heh
<ndufresne> alyssa: for me opt-in / creating an MR does not sound painful at all, just to be encouraging here, i only use manual branch CI for CI dev, which I've been away from for some times in now, hence no urgency
* bentiss likes his idea better actually: rely on project/group maintainers to build that list
<ndufresne> In GST, we quickly try and promote contributors into a role, so that works well for us
<ndufresne> (add more names to the autocompletion too, though I wish that was global sometimes)
<alyssa> bentiss: that'd probably be ok too :)
<alyssa> particularly if you could supply project/group maintainers a script to dump out the usernames for contributors in their org
<alyssa> (There are a /lot/ for mesa.)
<ndufresne> Would that mean we want to keep synching it, as we may remove/add roles
<alyssa> ndufresne: I'm less worried about that. Removing roles doesn't mean removing permissions, unless the reason for removing the permissions was, yknow, someone running a cryptominer or something
<alyssa> Adding roles, I guess people can MR themselves later, I'm more worried about not regressing anybody's workflow for the initial rollout
<bentiss> ndufresne: I think the problem is more of a jump start. I trust anybody added to that list by a maintainer would not be a cryptominer
<bentiss> and once you get new contributors, then you can ask them to add themself to the list
sewn has quit []
<bentiss> alyssa: should be easier done through the gitlab python module though (it handles pagination)
<__tim> I wonder if we could/should create a list of people in the gating script CI with a script api token that has the necessary permissions to query group membership (then that's not needed at the time the script runs), not sure if that would buy is anything
<bentiss> I have just uploaded my new version of the script. It's not enforced, again, but it should allow to check if the policy would prevent the pipelines. If it actually stops a pipeline, please ping me
<alyssa> __tim: that's exactly what we're discussing, afaiu
<__tim> ah sorry, only skimmed the backlog
<bentiss> __tim: no worries.
<bentiss> FWIW, I haven't tried today the ci-ok group solution we were discussing yesterday, because I am still unsure how I can provide a token that would allow just to retrieve the members of the group
<bentiss> I would have loved for the CI_JOB_TOKEN to allow that, but it's not the case :(
MajorBiscuit has quit [Ping timeout: 480 seconds]
<jenatali> alatiera: I'd really like to get Mesa Windows CI turned back on ASAP. The Windows build has already been broken in the few days it's been disabled
<jenatali> daniels: ^^
<alatiera> I turned one of the shared runners back on, think yday or the day before
<alatiera> its not the permanent solution, haven't yet looked at porting the pre-clone script to powershell or what extra we might need
<alatiera> but it should be working as before for now
<jenatali> As before, but only at half capacity?
<jenatali> Not sure if that's enough to feel comfortable turning CI back on
<__tim> for a long time we only had a single windows runner
<__tim> the second one was added mostly for redundancy
<jenatali> Alright, fair enough
<jenatali> Guess once we fix the build we can turn it back on
<alatiera> let's see how it goes with one runner for now
<alatiera> the whole issue is that if anything goes wrong again with the attacker I'd rather have to look only one of them rather than both
<alatiera> as well as giving them less resources to mine
<jenatali> Ack, makes sense
<__tim> now would probably also be a good opportunity to check that there's no more projects using the old 1809 windows runner
<__tim> so we can ditch that one
<alatiera> I think the only I saw last time was gfx-ci-box/mesa but can't find what pipeline or branch was it
alyssa has left #freedesktop [#freedesktop]
DodoGTA has left #freedesktop [#freedesktop]
DodoGTA has joined #freedesktop
agd5f has joined #freedesktop
alanc has quit [Remote host closed the connection]
alanc has joined #freedesktop
agd5f_ has quit [Ping timeout: 480 seconds]
mohamexiety has quit []
mvlad has quit [Remote host closed the connection]
Haaninjo has joined #freedesktop
vkareh has quit [Quit: WeeChat 3.6]
DodoGTA has left #freedesktop [#freedesktop]
DodoGTA has joined #freedesktop
mohamexiety has joined #freedesktop
<bentiss> actually, thinking about the group solution more, this might be easier than the one I got today: I "just" have to create an instance wide protected variable with a group token of the ci-ok group, and unsure I unset it before entering the script phase (not tested)
<bentiss> and with groups, I can invite other groups, meaning that giving CI rights is just adding someone to an existing group
<bentiss> and then I just drop all of the MR requirements. If a drive by contributor passes, someone with CI privileges just need to run the pipeline
DodoGTA has left #freedesktop [#freedesktop]
DodoGTA has joined #freedesktop
karolherbst_ is now known as karolherbst
DavidHeidelberg[m] has joined #freedesktop
<DavidHeidelberg[m]> ehm, ehm: "Looks like you don't have enough privileges, please see"
miracolix has quit [Remote host closed the connection]
AbleBacon has joined #freedesktop
danvet has quit [Ping timeout: 480 seconds]