Hi, * Paul Gevers [Wed Nov 06, 2024 at 08:00:21PM +0100]: > On 06-11-2024 07:43, Michael Prokop wrote:
> > Paul, do you know what could be the best option to reproduce the > > behavior of https://ci.debian.net/ (locally)? Because the problem > > seems to be environment specific, no one seems to have been able to > > reproduce it on salsa so far. :-/ > > As reported, it's flaky. Which means it might very well be only occurring > under heavy load, or when specific other things are happening on the system. > E.g. on i386, where only one debci worker runs per host, it seems to be much > less flaky than on the other hosts where we run multiple (up to 18 on amd64) > debci workers per host. You could try to spot patterns by matching > timestamps of passing and failing tests to the historical performance [1]. Ah, that's indeed very useful information, thanks Paul. > > Or what would be the best option to ignore this for now until it has > > been tracked down, mark the test as flaky? > > It looks like each autopkgtest stanza has only one test, so yes, marking it > flaky will resolve the problem (but also make the test close to worthless). > (If on the contrary it's part of a whole test suite, you'd rather want to > only mark the particular test as flaky or disable it, and not mark the > autopkgtest stanza as flaky). Right. Looking at the autopkgtest's of sssd I noticed, that inside debian/tests/login.exp there's a hardcoded timeout of 10 seconds, which very much could be related to the load situation and flaky behavior on Debian's CI infrastructure. I think it's worth increasing that timeout to 20 seconds, hopefully getting the autopkgtests on Debian's CI infrastructure under control. I'd appreciate review and merge/upload of the following change https://salsa.debian.org/sssd-team/sssd/-/merge_requests/34 - so we hopefully get sssd soon back into Debian/testing AKA trixie. regards -mika-
