Message ID | 20230601163123.1805282-7-berrange@redhat.com |
---|---|
State | New |
Headers | show |
Series | tests: enable meson test timeouts to improve debuggability | expand |
On 01/06/2023 18.31, Daniel P. Berrangé wrote: > The mtest2make.py script passes the arg '-t 0' to 'meson test' which > disables all test timeouts. This is a major source of pain when running > in GitLab CI and a test gets stuck. It will stall until GitLab kills the > CI job. This leaves us with little easily consumable information about > the stalled test. The TAP format doesn't show the test name until it is > completed, and TAP output from multiple tests it interleaved. So we > have to analyse the log to figure out what tests had un-finished TAP > output present and thus infer which test case caused the hang. This is > very time consuming and error prone. > > By allowing meson to kill stalled tests, we get a direct display of what > test program got stuck, which lets us more directly focus in on what > specific test case within the test program hung. > > The other issue with disabling meson test timeouts by default is that it > makes it more likely that maintainers inadvertantly introduce slowdowns. > For example the recent-ish change that accidentally made migrate-test > take 15-20 minutes instead of around 1 minute. > > The main risk of this change is that the individual test timeouts might > be too short to allow completion in high load scenarios. Thus, there is > likely to be some short term pain where we have to bump the timeouts for > certain tests to make them reliable enough. The preceeding few patches > raised the timeouts for all failures that were immediately apparent > in GitLab CI. > > Even with the possible short term instability, this should still be a > net win for debuggability of failed CI pipelines over the long term. > > Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> > --- > scripts/mtest2make.py | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/scripts/mtest2make.py b/scripts/mtest2make.py > index 179dd54871..eb01a05ddb 100644 > --- a/scripts/mtest2make.py > +++ b/scripts/mtest2make.py > @@ -27,7 +27,8 @@ def names(self, base): > .speed.slow = $(foreach s,$(sort $(filter-out %-thorough, $1)), --suite $s) > .speed.thorough = $(foreach s,$(sort $1), --suite $s) > > -.mtestargs = --no-rebuild -t 0 > +TIMEOUT_MULTIPLIER = 1 > +.mtestargs = --no-rebuild -t $(TIMEOUT_MULTIPLIER) > ifneq ($(SPEED), quick) > .mtestargs += --setup $(SPEED) > endif Basically Ack, but could you please double-check that "make check -j$(nproc)" still works if configure has been run with "--enable-debug" ? ... maybe we need to adjust the multiplier in that case... Thomas
diff --git a/scripts/mtest2make.py b/scripts/mtest2make.py index 179dd54871..eb01a05ddb 100644 --- a/scripts/mtest2make.py +++ b/scripts/mtest2make.py @@ -27,7 +27,8 @@ def names(self, base): .speed.slow = $(foreach s,$(sort $(filter-out %-thorough, $1)), --suite $s) .speed.thorough = $(foreach s,$(sort $1), --suite $s) -.mtestargs = --no-rebuild -t 0 +TIMEOUT_MULTIPLIER = 1 +.mtestargs = --no-rebuild -t $(TIMEOUT_MULTIPLIER) ifneq ($(SPEED), quick) .mtestargs += --setup $(SPEED) endif
The mtest2make.py script passes the arg '-t 0' to 'meson test' which disables all test timeouts. This is a major source of pain when running in GitLab CI and a test gets stuck. It will stall until GitLab kills the CI job. This leaves us with little easily consumable information about the stalled test. The TAP format doesn't show the test name until it is completed, and TAP output from multiple tests it interleaved. So we have to analyse the log to figure out what tests had un-finished TAP output present and thus infer which test case caused the hang. This is very time consuming and error prone. By allowing meson to kill stalled tests, we get a direct display of what test program got stuck, which lets us more directly focus in on what specific test case within the test program hung. The other issue with disabling meson test timeouts by default is that it makes it more likely that maintainers inadvertantly introduce slowdowns. For example the recent-ish change that accidentally made migrate-test take 15-20 minutes instead of around 1 minute. The main risk of this change is that the individual test timeouts might be too short to allow completion in high load scenarios. Thus, there is likely to be some short term pain where we have to bump the timeouts for certain tests to make them reliable enough. The preceeding few patches raised the timeouts for all failures that were immediately apparent in GitLab CI. Even with the possible short term instability, this should still be a net win for debuggability of failed CI pipelines over the long term. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> --- scripts/mtest2make.py | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)