ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput | register your nick to speak
<pq>
e78, no-one wants spying on their machine, which is why no arbitrary program should be allowed to take screenshots at arbitrary times, especially without the user noticing. However, the end user (not the screenshooting program) also needs to have a way of letting the screenshots they want to be taken, without disturbing. Making this difference is surprisingly difficult.
godvino has joined #wayland
devilhorns has joined #wayland
tanty has quit [Remote host closed the connection]
tanty has joined #wayland
godvino has quit [Read error: Connection reset by peer]
godvino has joined #wayland
godvino has quit [Read error: Connection reset by peer]
junaid has quit [Remote host closed the connection]
kts has quit [Quit: Konversation terminated!]
<pq>
emersion, could you invite swick[m] to the Wayland group in Gitlab, e.g. with Reporter access. I think that should allow him to run CI shared runners on his own, which is what his wayland-protocols fork needs I guess.
<emersion>
do we need to do this for all contributors?
<emersion>
if so, please investigate a better way
<pq>
I guess changing wayland-protocols CI rules might work
<pq>
which we would need to do on all projects, which might allow running CI on MRs only.
<pq>
I have special CI access through gitlab groups, which is why my MRs targeting any repo do not have a problem.
<pq>
...I believe
eroc1990 has joined #wayland
<swick[m]>
yeah, your pipeline succeeded but once I merged that it ran a pipeline on my branch which failed
<pq>
well, *I* can just go and click a button to run anyone's CI job, so I guess I'll just do that.
<swick[m]>
and that pipeline is not part of the MR on wayland-protocols even though its the same branch
<swick[m]>
so, detached pipelines didn't help here
<pq>
now that particular merged MR is green again
<daniels>
I agree that it would be great to give CI to everyone who registered accounts, but we had to not do that because we kept repeatedly getting DoSed by crypto miners
<swick[m]>
I don't really care about it as long as our workflow for the color stuff works but it doesn't and I don't know how to make it work again
<emersion>
if you want to trust a user for CI, there is a CI-OK group
<jadahl>
add a 'wip/color' branch to wayland/w-p and develop it there instead?
<pq>
emersion, exactly the CI-OK group. That's why I asked you to add swick[m] to Wayland group which is part of the CI-OK group.
<pq>
The only thing I can understand working going forward is that either people get added to the groups that are members of the CI-OK group, or those who have CI-OK powers need to manually go and run each pipeline for anyone who does not have that power.
<daniels>
^ yep
<pq>
all these temporary intermediate workarounds are just confusing me
<pq>
ok, so now that I've understood this, I know that every MR whose pipeline refuses to run, someone CI-OK-powered needs to make a quick review to make sure it's not abuse and click a button to let CI run.
<pq>
and you have to hit force-reload in Firefox to see the MR page updated, otherwise it stays red >_<
<pq>
regular reload is not enough
<daniels>
yeah, no-one likes the workarounds
<pq>
well, they completely stop working
<pq>
so why bother adjusting .gitlab-ci.yml at all
nerdopolis has joined #wayland
nerdopolis has quit []
nerdopolis has joined #wayland
<daniels>
eh?
<daniels>
detached MR-context pipelines are the thing you want regardless of whether or not further restrictions are applied
<pq>
that I did not understand from the write-up
nerdopolis has quit []
<daniels>
things may get more painful than they currently are if the abuse is persistent, but hopefully that won't be the case
<daniels>
even if it is the case, it's not like you'd need to delete that snippet in order to unbreak things - it's a good thing in and of itself
<pq>
Why was it a good thing in and of itself again?
<daniels>
because it means that the pipelines run associated with the MR itself and the parent project, rather than only running in the context of the user's forked branch linked only to the commit SHA with no indication that it's related to an MR
nerdopolis has joined #wayland
<pq>
ok, what's the benefit? Proposed new CI imaged get created directly in the project registry instead of the user's registry?
<pq>
*images
<daniels>
nah, it's a bit more nuanced than that, but basically it makes it less complicated to try and create sensible rules
<daniels>
I'm sorry if I'm not giving a concise five-point explanation of the differences, but that's because they're not easy to explain, unless you understand enough of how it works that you already know what the differences are
<daniels>
there are links from that issue which offer as much detail as you'd care to know
<pq>
oh, so it makes more complex rules possible, if one would happen to need those
<pq>
"Note that currently a non project member can run the CI with that workaround. In one month from now, only project members will get the policy validated for them. Drive-by contributors will require a manual action from a project member."
<pq>
Is that literally project members, or is it the group members?
<daniels>
group members are implicitly project members
<pq>
but project members are not implicitly group members, so which one does the policy check?
<pq>
only group members get CI powers now, project members don't
<daniels>
it checks the ci-ok group to see if the user is allowed to execute ci - and that is members of the top-level wayland group
<daniels>
it further (and this is only possible with the .gitlab-ci.yml snippet) checks to see if the pipeline is running in MR context by a user who can push to that project
<daniels>
so: both work
i509vcb has joined #wayland
<pq>
oh yeah, it wouldn't help anything if that too was checking group membership, so it has to be about project membership.
<pq>
I suppose adding people to a project is more common and easier and gives CI access only with that project, and not for everything like with the groups.
kts has joined #wayland
nerdopolis has quit [Remote host closed the connection]
The_Company has joined #wayland
The_Company has quit [Read error: Connection reset by peer]