| bluca | andersson1234: hi, seems like we are losing result reports again since the queue got unclogged | 16:07 |
|---|---|---|
| bluca | eg this PR shows all pending https://github.com/systemd/systemd/pull/32521 | 16:07 |
| bluca | but only the s390x jobs show in the queue, nothing else either running/queued https://autopkgtest.ubuntu.com/running#pkg-systemd-upstream | 16:07 |
| bluca | and the s390x queue is still long so sounds like it's expected that's queued, and the others are empty so it sounds to me they did run | 16:08 |
| bluca | it's intermittent too | 16:08 |
| bluca | most PRs show all the results, it's just a few that don't | 16:08 |
| Skia | bluca: we have had some issues with some jobs being lost in case of worker restart | 16:08 |
| Skia | that's something we want to fix, because it's pretty bad | 16:08 |
| Skia | I guess that's a good occasion to see about that documentation I just updated, telling us how to retrigger test in the infra? :D | 16:09 |
| bluca | ah thanks, if it's a known issue then no problem, just wanted to be sure | 16:10 |
| Skia | btw, do you think it would be possible to only trigger autopkgtest on relevant code changes? I had my documentation PR triggering some tests, but that would be totally irrelevant, and although it's quite fine on amd64, on s390x we don't have much workers | 16:10 |
| Skia | also, we should see to implement a way of dropping the queued test requests when they are no longer needed, like the documentation MR just got merged, so I guess we could drop the related tests, especially if they haven't been scheduled to run yet | 16:12 |
| bluca | yeah I had a WIP patch but never manage to make it work | 16:14 |
| bluca | as it's not trivial, need to do some git-tery stuff | 16:15 |
| bluca | but I do want to get back to that | 16:15 |
| Skia | oh great, that would be nice! | 16:15 |
| bluca | for cancelling jobs yeah that would be great, but I don't think I can do it on my side? | 16:15 |
| bluca | the infra side should notice that a new request was for a PR that is already queued/running and take care of that | 16:15 |
| bluca | from the PR ID | 16:16 |
| Skia | well, as of now, not really, but we have a way to drop tests as admins, so you could always come up and say "hey, please drop tests for PR #123" | 16:16 |
| Skia | you're talking about removing duplicates, right? | 16:16 |
| bluca | yes | 16:16 |
| bluca | but we get too many PRs and they get too many updates to do that by hand | 16:16 |
| Skia | yes I know | 16:17 |
| Skia | we usually only do that for big packages in Ubuntu, where we can potentially drop hundreds of jobs at once | 16:17 |
| Skia | removing duplicates is a topic we've already talked about | 16:18 |
| bluca | for example, given s390x is all backed up, feel free to drop all pending jobs from our queue | 16:18 |
| Skia | oh, really? | 16:18 |
| Skia | that would certainly help :-) | 16:18 |
| bluca | yeah it's fine | 16:19 |
| Skia | done, thanks, that will help the s390x infra :D | 16:19 |
| Skia | I'm still getting familiar with that part of the system. Do you have a pointer to where your side triggers the test requests? | 16:23 |
| Skia | bluca: ^ | 16:23 |
| bluca | it's only visible to admins, but it's pretty simple, it's a github webhook | 16:24 |
| bluca | let me fetch the config | 16:24 |
| Skia | okay thanks, don't bother I imagine what it looks like | 16:24 |
| bluca | https://autopkgtest.ubuntu.com/request.cgi?release=noble&arch=amd64&package=systemd-upstream&build-git=https%3A%2F%2Fsalsa.debian.org%2Fsystemd-team%2Fsystemd.git%23debian%2Fmaster&ppa=upstream-systemd-ci/systemd-ci&env=CFLAGS=-O0%3BDEB_BUILD_PROFILES=pkg.systemd.upstream%3BTEST_UPSTREAM=1%3BCONFFLAGS_UPSTREAM=--werror%20-Dslow-tests%3Dtrue | 16:24 |
| bluca | that's the URL | 16:24 |
| Skia | thanks | 16:25 |
| bluca | and only the "pull request" type of event is enabled | 16:25 |
| Skia | ok | 16:25 |
| bluca | application/json content type | 16:25 |
| Skia | hehe, I'm not sure that does anything, that endpoint is dump af, and is incapable of returning json :D | 16:25 |
| bluca | that's the only thing we have on our side - and if there's anything else I need to click on to enable for cancelling duplicates or something, let me know | 16:26 |
| Skia | we want to add it though | 16:26 |
| Skia | for now, there isn't anything neither of us can do about that. I need to put some thoughts to what a cancellation mechanism would look like, then get to coding | 16:27 |
| andersson1234 | Sorry I missed this! I was afk for a little while whilst you both spoke. There's work currently in review allowing people to kill running tests from the webpage - we could look at expanding access to that for upstream systemd maintainers if you'd like. We can also definitely consider and triage a "cancellation" mechanism, but I think it requires some thought and discussion | 16:47 |
| andersson1234 | Skia: are we certain the jobs were *lost* with the systemd unit restarts? It's my belief the message should go back into the queue. | 16:48 |
| andersson1234 | bluca: also, you mentioned only triggering CI for *required* changes, the bash detailed here may be of use to you https://git.launchpad.net/qa-jenkins-jobs/tree/jobs/autopkgtest-cloud/jobs.yaml#n74 even if it is quite trivial | 16:50 |
| andersson1234 | it's a jenkins job, where we build our docs, but only want to do so for changes to specific files. So somewhat similar to what you describe | 16:51 |
| bluca | thanks for the ref | 17:10 |
| bluca | yeah being able to kill tests from the webpage would be a nice addition | 17:11 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!