tree 4e7d0ffed14b1dbdb26ffc0dac95a854707cc22c
parent bf83a1b39a89dfb76d57136ea04ee12937c0da3a
author Andrew Jeffery <andrew@codeconstruct.com.au> 1715777845 +0930
committer Andrew Jeffery <andrew@codeconstruct.com.au> 1715902959 +0930

scripts: unit-test: Replace outdated timeout logic

Back in 2019 William added a new code-path for exploiting a meson
project's 'valgrind' test setup, if one existed[1]:

[1]: https://github.com/openbmc/openbmc-build-scripts/commit/49d4e594e8959cd8764

At the time, the behavior of `meson test -t 0 ...` was to immediately
terminate. This was useful in the context of testing whether a project
provided the a particular test setup, as we could invoke `meson test -t
0 --setup=<name>` without any significant impact on CI execution time.

However, as of meson 0.57.0 the behavior of `meson test -t 0`
changed[2]:

> test() timeout and timeout_multiplier value <= 0
>
> test(..., timeout: 0), or negative value, used to abort the test
> immediately but now instead allow infinite duration. Note that
> omitting the timeout keyword argument still defaults to 30s timeout.
>
> Likewise, add_test_setup(..., timeout_multiplier: 0), or meson test
> --timeout-multiplier 0, or negative value, disable tests timeout.

[2]: https://mesonbuild.com/Release-notes-for-0-57-0.html#test-timeout-and-timeout_multiplier-value-0

The consequence of the change is that the test for the existence of the
named setup in the project now executes the test suite with timeouts
disabled when the named setup is provided by the project at hand.

Further, having established that the named setup is supported by the
project, the script then executes the test suite _again_[^1].

A useful observation at this point is the the output from the following
set of commands, using stdplus[3] as an example:

```
$ meson test --setup=__likely_not_a_setup__ -C build __likely_not_a_test__
Test setup '__likely_not_a_setup__' not found from project 'stdplus'.
$ meson test --setup=valgrind -C build __likely_not_a_test__
ERROR: *:__likely_not_a_test__ test name does not match any test
```

[3]: https://github.com/openbmc/stdplus

Using an unlikely test name we make it likely that we error out in the
case where the named test setup is supported by the project. We use this
as a substitute for the old behavior of `-t 0`.

[^1]: Though at least it sets a timeout multiplier of 10, rather than
      disabling the timeout.

Tested: Ran the CI container against:

- entity-manager, which does not define a 'valgrind' test setup
- stdplus, which does define a 'valgrind' test setup

Verified that `meson test` was invoked with `--wrapper valgrind` for
entity-manager, and `--setup valgrind` for stdplus.

Change-Id: I78090716dd2842e6f4485a69f353d15ca11b62d1
Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>