qemu-ppc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 2/9] tests/avocado: mark boot_linux.py long runtime instead o


From: Thomas Huth
Subject: Re: [PATCH 2/9] tests/avocado: mark boot_linux.py long runtime instead of flaky
Date: Mon, 8 Jan 2024 12:56:07 +0100
User-agent: Mozilla Thunderbird

On 07/01/2024 18.01, Nicholas Piggin wrote:
The ppc64 and s390x tests were first marked skipIf GITLAB_CI by commit
c0c8687ef0f ("tests/avocado: disable BootLinuxPPC64 test in CI"), and
commit 0f26d94ec9e ("tests/acceptance: skip s390x_ccw_vrtio_tcg on
GitLab") due to being very heavy-weight for gitlab CI.

Commit 9b45cc99318 ("docs/devel: rationalise unstable gitlab tests under
FLAKY_TESTS") changed this to being flaky but it isn't really, it just
had a long runtime.

So introduce a new AVOCADO_ALLOW_LONG_RUNTIME variable and make these
tests require it. Re-testing the s390x and ppc64 tests on gitlab shows
about 100-150s runtime each, which is similar to the x86-64 tests.
Since these are among the longest running avocado tests, make x86-64
require long runtime as well.

Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
  docs/devel/testing.rst      | 8 ++++++++
  tests/avocado/boot_linux.py | 8 ++------
  2 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/docs/devel/testing.rst b/docs/devel/testing.rst
index bd132306c1..3a9c1327be 100644
--- a/docs/devel/testing.rst
+++ b/docs/devel/testing.rst
@@ -1346,6 +1346,14 @@ the environment.
  The definition of *large* is a bit arbitrary here, but it usually means an
  asset which occupies at least 1GB of size on disk when uncompressed.
+AVOCADO_ALLOW_LONG_RUNTIME
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+Tests which have a long runtime will not be run unless that
+``AVOCADO_ALLOW_LONG_RUNTIME=1`` is exported on the environment.
+
+The definition of *long* is a bit arbitrary here, but it usually means a
+test which takes more than 100 seconds to complete.

For the qtests (and others), we are using "make check SPEED=slow", so what about just re-using the SPEED environment variable instead? IMHO that would be more consistent?

 Thomas





reply via email to

[Prev in Thread] Current Thread [Next in Thread]