| 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:56 |
| 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:57 |
| 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? | 09:58 |
| andersson123 | bluca: hi, I see | 12:49 |
| andersson123 | it seems there must be a bug in our script which reports the results | 12:49 |
| andersson123 | I'll take a look | 12:50 |
| andersson123 | does `GITHUB_STATUSES_URL` change per trigger? i.e. if you retrigger a test run from a PR, will that statuses url change? | 12:55 |
| 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:12 |
| bluca | ie if you search for 'UPSTREAM_PULL_REQUEST=33965' you'll see 2 different URLes over 8 jobs | 13:13 |
| bluca | let me try a manual retry and see what happens | 13:14 |
| 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:15 |
| andersson123 | okay, that's helpful, thank you :D | 13:18 |
| andersson123 | I think I have the issue, should have a fix soon | 13:25 |
| andersson123 | yes, I have a fix :) | 13:30 |
| 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:33 |
| bluca | nice, thanks | 13:39 |
| andersson123 | Skia: I'll ping you when it's ready | 13:43 |
| 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:32 |
| bluca | yeah sure, either of those works | 14:43 |
| bluca | like a month retention is more than enough | 14:43 |
| bluca | is that still too much? | 14:44 |
| andersson123 | No! A month is great. Thanks, that's very helpful | 14:51 |
| bluca | perfect | 15:12 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!