[09:53] bluca: with the recent arm64 queues being big, I've had the pleasure of seeing the duplicated requests removal script logging that it indeed removed some stuff. I just wanted to confirm on some PR that indeed there would be no duplicated tests results, but I can't actually find the results. Could you point me at where to look, from your upstream development pov, to get Ubuntu CI autopkgtest results? [09:53] thanks [09:58] they are reported in line to the github PR page [09:58] but only one result is displayed [09:58] ie, if there are multiple jobs, there is still only one result [09:58] so it's hard to see from there [10:00] this is an example where noble-arm64 succeeded: https://github.com/systemd/systemd/pull/33745 [10:00] this is pending: https://github.com/systemd/systemd/pull/33810 [10:00] here it failed: https://github.com/systemd/systemd/pull/33758 [10:01] on our side those are the only 3 cases that can happen for a given job [10:06] oh, I didn't see that the list of checks had a scrollbar, now it's very clear! [10:07] I guess the only one displayed is the last one, at least? [10:09] also, how come I find xnox there reporting the results? :D I guess one token somewhere belongs to him, but would it be doable to change that to an org of some kind, either canonical or systemd? [10:11] on whether it's the last one - that is a good question [10:12] I have noticed sometimes, when tests are failed and rerun, that is not always the case [10:12] as far as github is concerned, it should be the last one reported (ie that the rest api call is made for) [10:12] but not sure how the autopkgtest cloud side handles it [10:12] and yeah xnox set it up [10:13] but the token is stored on your side, so you would have to find where and how, and then yeah we could change to a different one [10:20] regarding last one reported: they should be reported to Github in more or less the same order as they've processed, but this looks highly asynchronous, so I would expect jokes in the system [10:21] it's not code I'm very familiar with, and I doubt anyone in the team would have more confidence than me in that knowledge either [10:23] as for the token, I've found it, so I guess I should make a card for us to change that at some point [10:23] thanks for the answers :-) [10:27] no problem - for the token if you want one from us that's fine, let me know when you get around to it and I'll figure out how to generate one [10:27] I think you need to have permission in the org where the results are posted, so one from canonical's org might not work [10:27] but I don't know for sure [10:28] oh, that would indeed probably be easier than getting one from canonical [10:28] and if there is a better chance that it works, I'm all in [10:28] the change is very easy on my side, so whenever you have the token, I can change it [10:32] let me try and figure out how :D [10:32] do you have any details by chance? [10:34] I really don't know github well, but I can tell you what the existing token looks like [10:34] that probably would help yes [10:36] `ghp_ABCDefgh1234andalltherestlikethat123 [10:36] ` [10:36] it actually doesn't lol :D [10:37] arg, sorry to hear :D [10:37] I meant what kind of token it is, like a "repository secret" [10:37] or an "organization personal access token" [10:37] and actually, was that the literal token? if so pasting on irc was probably a bad idea... [10:38] I've no idea, I just found it in a text file with no metadata on how it was generated [10:38] and no, that was not the real one :D [10:38] the real is just random mix of [a-zA-Z0-9] [10:39] eheh ok [10:39] ghp might suggest "personal" [10:39] let me try to google a bit [10:39] https://github.blog/2021-04-05-behind-githubs-new-authentication-token-formats/ [10:40] > `ghp` for Github personal access tokens [10:48] ugh these personal tokens expire after a year [10:48] huh, that's short [10:50] eh we'll have to deal with it [10:50] I have generated it, how do we transfer it securely to you? [10:50] anykind of token would do, it seems [10:50] either Matrix (@skia:matrix.hya.sk) or email with GPG (key on LP: https://launchpad.net/~hyask) [10:52] sent via mail [10:53] I hoped I ticked the right boxes to allow access [10:53] I selected commit status and pr status [10:53] please give it a spin on some random PR and let me know if it works [11:01] the change is applied, but I just had a doubt on the username part, that was `xnox`, and just put `systemd` instead, I hope it'll work [11:01] now to force it to run, I need to dig a bit into the asynchronous system to see how to put a message in the system [11:14] "Last used: Last used within the last week" [11:14] something happened :D [11:14] :D [11:14] I see the script running [11:15] but I see a lot of `ignoring due to different test env`, so I didn't find where it tried to update something [11:17] https://github.com/systemd/systemd/pull/32363 this one has a status, `noble-ppc64el`, with your avatar on it [11:18] so, still not the org itself, but I think that's an improvement [11:18] ah perfect [11:18] so you cannot create tokens in an org [11:18] it has to be a member [11:18] but with these new PAT you can give ownership to the org [11:19] ie, it shows up under the org's settings unlike the xnox one [11:19] okay, so that's definitely better [11:19] ie they show up under https://github.com/organizations//settings/personal-access-tokens/active [11:19] while previously they were only under an individual's [11:20] wonderful! \o/ [11:21] is the switch permanent? if so, I can ask xnox to drop the previous token [11:21] I had a backup to be able to rollback, but since this is working, I don't see a reason not to make the change permanent [11:22] ok I'll ping him [11:22] thanks for the help [11:22] yeah, thanks too, you had your part :-)