[09:56] <bluca> andersson123: I have a good example of the issue with reporting retries
[09:56] <bluca> https://github.com/systemd/systemd/pull/33963
[09:56] <bluca> noble-amd64 failed with a testbed error, so I submitted a manual retry for that PR
[09:56] <bluca> it showed as in progress for a few minutes, but then it was immediately changed back to failed, pointing to the old log
[09:57] <bluca> while the retry is still in progress and can be seen on https://autopkgtest.ubuntu.com/running#pkg-systemd-upstream
[09:57] <bluca> (search for 33963)
[09:58] <bluca> github purely shows the last received state on those PRs, so there must be something sending back the failed status from the autopkgtest cloud?
[12:49] <andersson123> bluca: hi, I see
[12:49] <andersson123> it seems there must be a bug in our script which reports the results
[12:50] <andersson123> I'll take a look 
[12:55] <andersson123> does `GITHUB_STATUSES_URL` change per trigger? i.e. if you retrigger a test run from a PR, will that statuses url change?
[13:12] <bluca> I don't know for sure, but it looks different on each force push
[13:12] <bluca> but it's the same for all 4 per-arch jobs from the same push
[13:13] <bluca> ie if you search for 'UPSTREAM_PULL_REQUEST=33965' you'll see 2 different URLes over 8 jobs
[13:14] <bluca> let me try a manual retry and see what happens
[13:15] <bluca> I got the same url as the last one on a manual retry
[13:15] <bluca> so I guess a force push on the branch means new URL, manual trigger directly to autopkgtest means same URL
[13:18] <andersson123> okay, that's helpful, thank you :D
[13:25] <andersson123> I think I have the issue, should have a fix soon
[13:30] <andersson123> yes, I have a fix :) 
[13:33] <Skia> andersson123: please give me the review, I have a bit of context on that since recently :-)
[13:33] <Skia> should be able to give it a look tonight
[13:39] <bluca> nice, thanks
[13:43] <andersson123> Skia: I'll ping you when it's ready 
[14:32] <andersson123> bluca: I have a quick question :) The containers holding your results are obviously quite large, as you know from the issues with pagination. My question is - can we delete results that are older than a certain X days? What would be a comfortable value for X for you? Or perhaps, instead of X days old, we just keep X number of results. What do you think?
[14:43] <bluca> yeah sure, either of those works
[14:43] <bluca> like a month retention is more than enough
[14:44] <bluca> is that still too much?
[14:51] <andersson123> No! A month is great. Thanks, that's very helpful 
[15:12] <bluca> perfect