[16:07] <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:08] <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:09] <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:10] <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:12] <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:14] <bluca> yeah I had a WIP patch but never manage to make it work
[16:15] <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:16] <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:17] <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:18] <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:19] <bluca> yeah it's fine
[16:19] <Skia> done, thanks, that will help the s390x infra :D
[16:23] <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:24] <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:25] <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:26] <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:27] <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:47] <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:48] <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:50] <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:51] <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 
[17:10] <bluca> thanks for the ref
[17:11] <bluca> yeah being able to kill tests from the webpage would be a nice addition