Re: New consul package not migrating to testing because of patroni autopkgtest?
Hi,
Am Mittwoch, den 09.12.2020, 20:32 +0100 schrieb Paul Gevers:
> On 09-12-2020 20:21, Reinhard Tartler wrote:
> > Turns out that the test errors were transient and someone scheduled
> > retries for amd64 which passed. It seems we still have errors on arm64
> > and I expect that to go away with some retries as well.
> >
> > I noticed that the arm64 build also required 2 give-backs (that I
> > scheduled using the web-ui) to build successfully. That's why I'm
> > optimistic about retrying the autopkg tests for consul.
>
> These kind of build failures should be fixed.
There's no build failures, are there? Also patroni is Arch: all and in
python so I find it somewhat hard to believe it (and not python itself,
or one of patroni's (build-)dependencies) has arm64 specific issues.
Before etcd got fixed for arm64, it was indeed not possible to
build/test patroni on arm64, but that has been resolved a while ago.
> Builds that regularly fail are not OK. Same goes for autopkgtest.
> Flaky tests are RC.
Well ok, but I have to say that patroni is not flaky at all either on my
development notebook or on the apt.postgresql.org buildfarm as far as
testing/unstable is concerned:
https://pgdgbuild.dus.dg-i.net/job/patroni-binaries/129/
https://pgdgbuild.dus.dg-i.net/job/patroni-binaries/128/
https://pgdgbuild.dus.dg-i.net/job/patroni-binaries/127/
https://pgdgbuild.dus.dg-i.net/job/patroni-binaries/126/
https://pgdgbuild.dus.dg-i.net/job/patroni-binaries/125/
https://pgdgbuild.dus.dg-i.net/job/patroni-binaries/124/
Except for the #124 one, they are all green, though admittedly,
pgdgbuild builds Arch:all packages on amd64 only.
The behave tests are timing-sensitive in so far as they assume some
actions to happen in X seconds, maybe timing is off on the ci.debian.net
runners. Unfortunately, it is rather difficult to read the logs because
it is unclear when exactly an assertion happened.
Paul, I think what would be helpful is timestamps prepending each log
line, so that one can attribute failures to the dumped logs, similar to
what Jenkins is doing:
https://pgdgbuild.dus.dg-i.net/job/patroni-binaries/129/architecture=amd64,distribution=sid/console
Though of course, this can also be done on the patroni packaging side. I
couldn't find an obvious command-line switch for behave to add
timestamps, so now I've uploaded a new patroni package that pipes the
behave output through moreutils' ts.
If the problem still exists, I will try to have a look at the next round
of failure logs, please remind me if I forget.
Michael
--
Michael Banck
Projektleiter / Senior Berater
Tel.: +49 2166 9901-171
Fax: +49 2166 9901-100
Email: michael.banck@credativ.de
credativ GmbH, HRB Mönchengladbach 12080
USt-ID-Nummer: DE204566209
Trompeterallee 108, 41189 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer
Unser Umgang mit personenbezogenen Daten unterliegt
folgenden Bestimmungen: https://www.credativ.de/datenschutz
Reply to: