Is d/t/ldap-user-group-krb5-auth also flaky? Because it uses the same
expect script:
d/t/ldap-user-group-krb5-auth:
...
# tests begin here
run_common_tests
# login works with the kerberos password
echo "The Kerberos principal can login on a terminal"
kdestroy > /dev/null 2>&1 || /bin/true
/usr/bin/expect -f debian/tests/login.exp "${ldap_user}"
"${kerberos_principal_pw}" "${ldap_user}"@"${myrealm}"
d/t/ldap-user-group-ldap-auth:
...
# tests begin here
run_common_tests
echo "The LDAP user can login on a terminal"
/usr/bin/expect -f debian/tests/login.exp "${ldap_user}" "${ldap_user_pw}"
On Wed, Nov 6, 2024 at 4:00 PM Paul Gevers <elb...@debian.org> wrote:
>
> Hi
>
> 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].
>
> > 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).
>
> Paul
>
> [1] https://ci.debian.net/munin/
>
