06:55 <mupuf> bentiss, daniels: On a related note to the expiring tokens, did you notice that you can now give the allow rotation role to tokens? This can allow tokens to be rotated by their user. I'll add support for that in CI-tron so that we don't have to have tokens that never expire and could get leaked without our knowledge.

07:00 <bentiss> mupuf: that's interesting, but we'd till need to update the deployments where they are used, no? I don't understand how the environment variable can be changed otherwise...

07:00 <bentiss> daniels: no worries and enjoy your time off

07:00 <mupuf> bentiss: yes, I realized that. That's why I said it was a related note rather than a potential fix ;)

07:01 <mupuf> maaaaayyybe the API role could update CI variables?

07:01 <mupuf> no idea...

07:01 <bentiss> and also, how this is working? because once the token is generated, you can't read it on the UI, so... that feels weird :)

07:03 <bentiss> looking into the docs... it seems you can use the token itself to call the 'rotate' api endpoint, and this endpoint only

07:04 <bentiss> so we'd still need some service which checks for the expiration date, and calls the api before expiring and update everything... not sure I want to work on that :(

07:48 <mupuf> bentiss: yes, that makes no sense in this case

07:49 <mupuf> but it does make sense for the registration tokens we give out to farm owners: We could set an expiration date of 1 month, and let them rotate the token. In other words, they would keep access as long as their farm remains online

07:50 <mupuf> and they would have to ask again if it lapsed

07:50 <bentiss> yeah, as long as I don't have to do more work :)

07:50 <mupuf> oh, absolutely, no work needed from you ;)

07:50 <mupuf> just a little bit of work for me in CI-tron ;)

07:51 <bentiss> heh

08:17 <dj-death> is there a problem with Marge atm? : https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36916

08:40 <bentiss> it successfully merged https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37165 and https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37003 so it must come from the pipeline definition

08:41 <bentiss> (IOW, there is no extra logs from the console)

10:02 <daniels> dj-death: don't push a rebase with a Part-of trailer

10:03 <daniels> if the rebase is a no-op (base commit is the same, commit message is unchanged), marge can't actually push the new changes, so the pipeline doesn't actually start

10:03 <daniels> the easy way is to not include the Part-of trailer in your commit messages

10:03 <daniels> I did try to push a fix upstream for that but it died in review

10:25 <dj-death> daniels: thanks

10:26 <dj-death> just need to drop it if inserted by Marge

10:27 <daniels> yeah

17:04 <eric_engestrom> lists.fd.o is timing out (and this time it's not just on my wifi 😅)

17:08 <eric_engestrom> daniels: for your fix of the no-op rebase, I understand your arguments, but iirc it would kill the "reassign to marge after the pipeline timed out because it actually finished a minute later" use-case, which I think is more important, so unless we can have both, I don't think your fix is worth it. maybe you can make your code only execute if the current pipeline is not created by marge, or something like that?

17:09 <daniels> eric_engestrom: sure, I can see that

17:09 <daniels> otoh that case does require manual intervention anyway, as it's very rare for the queue to be completely empty

17:10 <eric_engestrom> sure, but it's easy enough to unassign/reassign a couple of MRs to put them back in the queue behind the MR we want

17:32 <eric_engestrom> daniels: comment posted: https://gitlab.com/marge-org/marge-bot/-/merge_requests/445#note_2730804207