michaelh/zephyr
1
0
Fork 0
Code Releases Activity

twister: Fix description of relationship between filter and allow/exclude

Browse source 
The current description of the relationship between the tests filter
and the arch/platform allow/exclude was actually incorrect.

Let's fix it.

Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
This commit is contained in:
Alberto Escolar Piedras 2023-10-17 14:00:08 +02:00 • committed by Johan Hedberg
commit ec273d1357
1 changed files with 16 additions and 9 deletions
Download patch file Download diff file Expand all files Collapse all files

25
scripts/twister
View file

@ -142,15 +142,6 @@ pairs:
not (right associative) not (right associative)
all comparison operators (non-associative) all comparison operators (non-associative)
arch_allow, arch_exclude, platform_allow, platform_exclude
are all syntactic sugar for these expressions. For instance
arch_exclude = x86 arc
Is the same as:
filter = not ARCH in ["x86", "arc"]
The ':' operator compiles the string argument as a regular expression, The ':' operator compiles the string argument as a regular expression,
and then returns a true value only if the symbol's value in the environment and then returns a true value only if the symbol's value in the environment
matches. For example, if CONFIG_SOC="stm32f107xc" then matches. For example, if CONFIG_SOC="stm32f107xc" then
@ -159,6 +150,22 @@ pairs:
Would match it. Would match it.
Note that arch_allow, arch_exclude, platform_allow, platform_exclude
are not just syntactic sugar for filter expressions. For instance
arch_exclude = x86 arc
Can appear at first glance to have a similar effect to
filter = not ARCH in ["x86", "arc"]
but unlike "filter", these cause platforms to be filtered already during the testplan
generation. While "filter" does not exclue platforms at the testplan generation, and instead
relies on the result of running the build configuration stage. That is, to evaluate the filter
expression, cmake is run for that target, and then the filter evaluated as a gate for the
build and run steps.
Therefore filtering by using {platform|arch}_{exclude|allow} is much faster.
The set of test cases that actually run depends on directives in the testsuite The set of test cases that actually run depends on directives in the testsuite
files and options passed in on the command line. If there is any confusion, files and options passed in on the command line. If there is any confusion,
running with -v or examining the test plan report (testplan.json) running with -v or examining the test plan report (testplan.json)