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
alanc has quit [Remote host closed the connection]
alanc has joined #freedesktop
Consolatis_ has joined #freedesktop
vyivel_ has joined #freedesktop
sentriz_ has joined #freedesktop
lesbraz has joined #freedesktop
dakr has quit [Remote host closed the connection]
jvaclav has quit [Remote host closed the connection]
sentriz has quit [Remote host closed the connection]
Caterpillar has quit [Remote host closed the connection]
sbraz has quit [Remote host closed the connection]
lesbraz is now known as sbraz
vyivel has quit [Remote host closed the connection]
mrpops2ko has quit [Read error: Connection reset by peer]
Consolatis is now known as Guest14348
Consolatis_ is now known as Consolatis
dakr has joined #freedesktop
jvaclav has joined #freedesktop
sentriz_ is now known as sentriz
mrpops2ko has joined #freedesktop
Guest14348 has quit [Ping timeout: 480 seconds]
DragoonAethis has quit [Quit: hej-hej!]
DragoonAethis has joined #freedesktop
alarumbe has joined #freedesktop
scrumplex_ has joined #freedesktop
scrumplex has quit [Ping timeout: 480 seconds]
Kayden has quit [Quit: -> HT]
cascardo has quit []
cascardo has joined #freedesktop
JanC is now known as Guest14381
JanC has joined #freedesktop
Guest14381 has quit [Ping timeout: 480 seconds]
vimproved_ has joined #freedesktop
jvaclav8 has joined #freedesktop
jvaclav has quit [Read error: Connection reset by peer]
jvaclav8 is now known as jvaclav
vimproved has quit [Ping timeout: 480 seconds]
eluks has quit [Remote host closed the connection]
eluks has joined #freedesktop
gchini has joined #freedesktop
georgc has joined #freedesktop
gchini has quit [Ping timeout: 480 seconds]
Asmadeus has quit [Quit: relocating]
<DemiMarie>
bentiss: Iām not sure about GitLab but I know that MediaWiki supports explicit cache purging via PURGE requests
toponeyankee has quit [Remote host closed the connection]
troubledpony has joined #freedesktop
swatish2 has joined #freedesktop
i-garrison has quit []
i-garrison has joined #freedesktop
mczaplin has joined #freedesktop
ximion has quit [Remote host closed the connection]
pjakobsson has joined #freedesktop
AbleBacon has quit [Read error: Connection reset by peer]
mczaplin has quit [Ping timeout: 480 seconds]
Traneptora_ has joined #freedesktop
troubledpony has quit [Remote host closed the connection]
Traneptora has quit [Ping timeout: 480 seconds]
jsa1 has joined #freedesktop
sghuge has quit [Remote host closed the connection]
sghuge has joined #freedesktop
mczaplin has joined #freedesktop
todi has joined #freedesktop
<slomo>
__tim: you can still cancel a CI pipeline by pushing updates to the branch at least ;) but that's all quite broken indeed
<slomo>
bentiss: earlier this week (before yesterday's update) I noticed CI pipelines being similarly broken btw. which also looked like a caching problem. i had a couple of pipelines where i retried a job. that job continued to show up as failed in the "inline view" of the pipeline in the MR (even when reloading the whole page) but the new ones showed up
<slomo>
when looking at the full page of the pipeline. when going to the failed job, the retry button was also gone. just in case that helps anything with debugging
mvlad has joined #freedesktop
<bentiss>
slomo: the problem is that we made some tests bypassing fastly, and the retry button was not there as well
<bentiss>
and I just redid that: changed /etc/hosts, open a fresh browser, logged in -> no retry button, then enter admin mode -> still no button. It really seems that something is broken at the gitlab level
<nirbheek_>
Funny, screencasts made by GNOME can't be opened by Element in the browser :)
<mvlad>
nirbheek_, most likely that the link generated is wrong, but a merge link is also given when doing that in the cmd line (when you do git push). Maybe that's a work-around for the time being, until that gets looked into.
vyivel_ has quit [Remote host closed the connection]
vyivel has joined #freedesktop
___nick___ has quit [Remote host closed the connection]
nrm has joined #freedesktop
nrm has left #freedesktop [Leaving]
<nirbheek_>
It's the same link as on the command-line
<nirbheek_>
Also tried wiping cookies and logging in again
<nirbheek_>
Worked fine when I renamed the branch from f42-m4 to f42m4 so there might be some strange bug in gitlab there
<bentiss>
(or in a couple of minutes for the propagation to happen)
<bentiss>
basically, the fishy part is that when you created the fork, gitlab returned a 302 which was cached by fastly while it shouldn't have, but this is only locale to your cache near you
<bentiss>
bummer
<kusma>
Yep, works
<kusma>
Thanks
<bentiss>
maybe I'll need to check on the return value (404 or 302) and force not to cache them
<kusma>
BTW, I had some issues that looked like caching last night as well; I published an update on gitlab pages (migrating the x.org wiki to pages), and I didn't observe new content unless I changed the pages URL...
<bentiss>
for gitlab pages, I haven't done any tuning of the data. And I'm not sure I want. It's painful when you develop, but it save quite some cycles on the servers (26% AFAICT)
<bentiss>
in those situations, add an override to your /etc/hosts with the IP from ssh.gitlab.fd.o, but do not forget to remove it once it's done
<bentiss>
another soltuion would be to have the gitlab-pages job send a PURGE request to fastly, like DemiMarie suggested (though for gitlab), but that means that I'll have to give fastly API keys to random people, which might not be ideal
Traneptora_ has quit [Quit: Quit]
Traneptora has joined #freedesktop
<__tim>
or you set up an intermediary service/api somewhere that can be pinged
<bentiss>
-ENOTIME TBH
<__tim>
yeah, ofc
Traneptora has quit []
<bentiss>
actually... if we were to receive a webhook event, that should be trivial to do with hookiedookie
<bentiss>
but really... -ENOTIME
swatish2 has quit [Ping timeout: 480 seconds]
Traneptora has joined #freedesktop
<kusma>
bentiss: Yeah, it's not clear how to avoid that... I suppose things would eventually update, right? I suppose we can't make fastly check for new content more often? Of course there's no "correct" balance there either.
<bentiss>
kusma: we can parametrize the cache time, yes, but not sure it'll be very interesting to shorten it, because updates are punctuals
<kusma>
Ideally, gitlab would send the purge-request rather than the repos, but I guess that'd be painful to make happen.
<bentiss>
yeah. We can rely on webhooks and hookiedookie to send that request, but that would be per repo, and a lot of PITA
<kusma>
Gotcha. Thanks for the tips!
mczaplin has quit [Ping timeout: 480 seconds]
swatish2 has joined #freedesktop
<Consolatis>
uh? would would any cache remember 302 redirects? its a temporary one after all. 301 is the one for permanent redirects
arekm has quit [Remote host closed the connection]
<Consolatis>
why would*
mczaplin has joined #freedesktop
arekm has joined #freedesktop
digetx has joined #freedesktop
swatish21 has joined #freedesktop
swatish2 has quit [Ping timeout: 480 seconds]
<MathieuBridon[m]>
Hi everyone, I'm having trouble fetching/pushing from/to the new git remote š
<MathieuBridon[m]>
It says permission denied (publickey)
<MathieuBridon[m]>
I did add my public ssh key in the settings for my account
<eric_engestrom>
MathieuBridon[m]: `ssh.gitlab.freedesktop.org/cangjie/ibus-cangjie.git` that first `/` slash, right after the hostname, should be a `:` colon
<eric_engestrom>
it's not a valid ssh path right now, and gets interpreted as http instead
alarumbe has joined #freedesktop
swatish2 has joined #freedesktop
<MathieuBridon[m]>
Ah, because I didn't use `git@`? š¤
mczaplin has quit [Ping timeout: 480 seconds]
swatish2 has quit [Ping timeout: 480 seconds]
MrCooper_ has joined #freedesktop
<eric_engestrom>
ah, that too, I also missed that
MrCooper has quit [Ping timeout: 480 seconds]
haaninjo has joined #freedesktop
<svuorela>
The ui seems a bit sluggish/slow. Is something going on ?
jsa1 has quit [Ping timeout: 480 seconds]
MrCooper_ is now known as MrCooper
<MrCooper>
gitlab UI feels quite slow ATM, like slower than before the migration
atticf has quit [Remote host closed the connection]
atticf has joined #freedesktop
<bentiss>
works fine here
guludo has quit [Ping timeout: 480 seconds]
lsd|2 has joined #freedesktop
D-HUND is now known as debdog
ximion has joined #freedesktop
<MathieuBridon[m]>
ok, seems I needed to use ssh://git@..., I could push now, thanks š
AbleBacon has joined #freedesktop
tlwoerner has joined #freedesktop
<__tim>
so I think I have solved the problem with job trigger / re-try permissions for merge request pipelines in GStreamer
<__tim>
If I change the Protected Branches permissions to Allowed to merge = Developers + Maintainers for the '*' wildcard (which is all branches that are not main or stable 1.xy branches), it works
<__tim>
although I wonder what will now happen for external contributors who do not have developer rights
<__tim>
if they can still trigger their MR pipelines
<__tim>
to be seen
Kayden has joined #freedesktop
guludo has joined #freedesktop
<__tim>
hrm, is it expected that merge request pipelines now run in the target project namespace and no longer in the fork's namespace?
vimproved_ has quit [Remote host closed the connection]
vimproved has joined #freedesktop
kasper93 has quit [Read error: Connection reset by peer]
vimproved has quit [Remote host closed the connection]
vimproved has joined #freedesktop
digetx has quit [Ping timeout: 480 seconds]
georgc has quit [Quit: Leaving]
gchini has joined #freedesktop
kasper93 has joined #freedesktop
<bentiss>
__tim: it has always been the case for developers + maintainers + owners
kasper93 has quit [Ping timeout: 480 seconds]
<__tim>
not sure that's true, I checked some older MR pipelines and they were tagged as 'merge_request' and 'fork'
<__tim>
and the newer ones are just merge_request
<__tim>
not sure when it changed, but I think it was mentioned on the gitlab mr doc page I skimmed earlier
<__tim>
I think there is/was some secret project option that's only accessible from the api or so, and maybe that default now got toggled or something, dunno
<__tim>
but looking at the MR pipeline history, it's exactly when the MR pipelines changed from merge_request + fork to just merge_request that our problems started, and I guess it make sense then that that's related to the merge permissions in the target project