daniels 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
koike has joined #freedesktop
koike is now known as Guest149
<Guest149>
shashanks_: could you point me to a pipeline ?
<Guest149>
shashanks__: ^
Guest149 is now known as koike
cstub has quit []
chrysn[m]1 has joined #freedesktop
jenatali has joined #freedesktop
tintou has joined #freedesktop
nielsdg has joined #freedesktop
cmeissl[m] has joined #freedesktop
columbarius has joined #freedesktop
co1umbarius has quit [Ping timeout: 480 seconds]
ttancos[m] has joined #freedesktop
i509vcb has quit [Quit: Connection closed for inactivity]
pixelcluster_ has joined #freedesktop
pixelcluster has quit [Ping timeout: 480 seconds]
psykose has quit [Remote host closed the connection]
psykose has joined #freedesktop
aenderboy[m] has joined #freedesktop
ximion has quit [Quit: Detached from the Matrix]
bmodem has joined #freedesktop
swatish2 has joined #freedesktop
lack has quit [Read error: Connection reset by peer]
lack has joined #freedesktop
ylatuya[m] has joined #freedesktop
sauce has quit [Ping timeout: 480 seconds]
bmodem has quit [Ping timeout: 480 seconds]
bmodem has joined #freedesktop
bmodem has quit [Remote host closed the connection]
bmodem has joined #freedesktop
sauce has joined #freedesktop
i509vcb has joined #freedesktop
AbleBacon has quit [Read error: Connection reset by peer]
<eric_engestrom>
(it's blocking the lima farm from being re-enabled, so it would be good if we can merge this today)
<eric_engestrom>
it's essentially a revert of the partial revert I did a few days ago, because in the meantime daniels added an `if MR` condition to all of these, which was the right fix for the part I removed too, so re-adding it *with the `if MR` condition* :)
lack has quit [Read error: Connection reset by peer]
shashanks_ has quit [Ping timeout: 480 seconds]
lack has joined #freedesktop
pixelcluster_ has quit []
pixelcluster has joined #freedesktop
ximion has joined #freedesktop
ximion has quit [Quit: Detached from the Matrix]
Ahuj has quit [Ping timeout: 480 seconds]
cstub has quit [Read error: Connection reset by peer]
cstub has joined #freedesktop
cstub has quit []
<cwabbott>
I dunno what happened, but job filtering seems to have been broken recently, maybe just in branches and not MRs
<cwabbott>
that wasn't the case before I recently rebased that branch
tzimmermann has quit [Quit: Leaving]
<eric_engestrom>
cwabbott: not sure if this is what happened in your case, but in fork pipelines what gitlab counts for this is what changed from one push to the next
<eric_engestrom>
so eg. if you make a driver code change, push that, then amend the commit to add a doc change, and push that, the latest pipeline will only have docs jobs
<daniels>
yeah, so I think in this case we want to keep on going with the changes from this week, and just not look at changes in forks
<daniels>
so every fork always comes up with a full manual pipeline
<daniels>
(and then make sure that no-one ever clicks play but uses ci_run_n_monitor)
<daniels>
(otoh, making all the jobs when: manual rather than on_success for forks would achieve that, because you'd have to explicitly start every job in every stage you wanted, not just hit play on the container stage)
<eric_engestrom>
hmm yeah, +1 to making every job manual to make it too annoying for people to click on the web ui buttons
<eric_engestrom>
(shame we have to fight gitlab like this though :/)
<eric_engestrom>
that should be a simple `if: 'source == push && namespace != mesa' when: manual` at the top of each of the container/build/test rules
<daniels>
yeah, I like that actually ...
<daniels>
1) .common-rules (used by everything other than 'sanity'): manual run if not in MR/schedule context, no run if farm is being disabled in MR context
<daniels>
2) .container-rules (extending common): auto-run if MR/schedule context
<daniels>
3) .build-rules (extending common): auto-run if MR context and changes: *all-paths, auto-run if schedule context
<daniels>
4) .test-rules (extending common): auto-run if MR context and changes: *relevant-paths, auto-run if schedule context
<MrCooper>
to me, it seems to be working as designed: nothing changes, no jobs?
<daniels>
MrCooper: it makes CI semi-useless on non-MR branches though, and those can be a useful thing to test on
<MrCooper>
one can just (re-)run the jobs in a previous pipeline when something actually changed
<daniels>
like, if you have a branch with 15 invasive fdno commits, then the top commit changes doc/features.txt, you'll get a no-test pipeline, because the only change is doc/
<MrCooper>
yep, that's what I'd expect
<daniels>
and you can't reuse a previous pipeline, because the SHA to use is an immutable property of the pipeline
<daniels>
but then we might as well when: never branch pipelines, because the job set you'll get is essentially random
<daniels>
as it's not related to the changes in your actual branch
<MrCooper>
it really is, just not compared to the fork point
<MrCooper>
couldn't parse "can't reuse a previous pipeline, because the SHA to use is an immutable property of the pipeline", SHA as in commit ID?
<daniels>
yeah
<daniels>
so you can't take a pipeline for the commit you pushed last week and run it against the commit you pushed today
<daniels>
'not compared to the fork point' isn't helpful if you're in the habit of having more than one commit per branch
<MrCooper>
that's not needed anyway, because nothing relevant has changed in the new commit
<MrCooper>
that's why the new pipeline doesn't have the jobs
<MrCooper>
just use the pipeline from the previous commit
jarthur has joined #freedesktop
<MrCooper>
anyway, just offering a different viewpoint, not standing in the way
<daniels>
right, but pipelines are only created per-push (not per-commit), and only for the top commit of a push
<daniels>
so unless you push once per commit, or create a new branch every time, you’re liable to get a pipeline only including part of what’s relevant
<MrCooper>
the relevant diff is actually the per-push one, not per-commit
<MrCooper>
so you get all the jobs corresponding to what changed in the push
<daniels>
hmm
AbleBacon has joined #freedesktop
<cwabbott>
in my case I think the code didn't change but the CI xfails did change
<cwabbott>
I was developing a bunch of stuff, got it to mostly work except for a ton of UnexpectedPass, then split off some of the fixes that resulted in UnexpectedPass into https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25225 (and updated the xfail list in src/freedreno/ci/)
<MrCooper>
sounds like the rules don't create jobs for xfails changes, they should though
<cwabbott>
after merging that I wanted to check that CI is actually green and no actual failures slipped through
<MrCooper>
would be the same issue in an MR which changes only xfails
<cwabbott>
so I rebased the remaining unmerged changes
bmodem has quit [Ping timeout: 480 seconds]
<cwabbott>
and I guess there weren't any intervening changes to src/freedreno, so the only thing that changed between pushes is the xfail list
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #freedesktop
<zmike>
is there some way to set a gitlab policy so that people with developer roles are never shown captchas?
<zmike>
I just got stuck in an infinite captcha loop yet again
<eric_engestrom>
daniels: that logic (the 4 steps you posted an hour ago) looks good to me; do you want to post that MR, or should I (next week)?
<eric_engestrom>
zmike: I'm not 100% sure but I think there's only a global "turn security off" button, nothing per user or access level