linux/poky.git, branch 4.2_M3

resulttool/regression: Improve matching of poor ptest test names

2023-02-26T11:59:52+00:00

Some test case naming is poor and contains random strings, particularly lttng/babeltrace but also curl. Truncating the test names works since they contain file and line number identifiers which allows us to match them without the random components, or in the case or curl, test IDs. Going forward we may be able to improve the test names but this tweak allows historical test results to work in reports. (From OE-Core rev: 541a2e2683531355e678fd93524a0c4a8c43a8ff) Signed-off-by: Richard Purdie

resulttool/regression: Ensure LTP results are only compared against other LTP runs

2023-02-26T11:59:52+00:00

If a test result contains LTP test results, it should only be compared with other runs containing LTP test results. (From OE-Core rev: 4dbbf2f4a85620a08dc2fa65095dc17fe6c530f8) Signed-off-by: Richard Purdie

oeqa/selftest: add test for yocto_testresults_query.py

2023-02-26T11:59:52+00:00

Add some tests for new yocto_testresults_query.py helper. First test is taken from yocto-autobuilder-helper feature which has moved in yocto_testresults_query (From OE-Core rev: 9ce28f685e4282d81f179877cbafd0a52fa887bd) Signed-off-by: Alexis Lothoré Signed-off-by: Richard Purdie

scripts: add new helper for regression report generation

2023-02-26T11:59:52+00:00

Add yocto-testresults-query script. This is a thin wrapper over resulttool which is able to translate tags or branch name to specific revisions, and then to work with those "guessed" revisions with resulttool (From OE-Core rev: b1460201b0f3d8fd7f977ac82f218bf9010d5573) Signed-off-by: Alexis Lothoré Signed-off-by: Richard Purdie

scripts/resulttool/regression: add metadata filtering for oeselftest

2023-02-26T11:59:52+00:00

When generating regression reports, many false positive can be observed since some tests results are compared while the corresponding tests sets are not the same, as it can be seen for example for oeselftest tests (oeselftest is run multiple time but with different parameters, resulting in different tests sets) Add a filtering mechanism in resulttool regression module to enable a better matching between tests. The METADATA_MATCH_TABLE defines that when the TEST_TYPE is "oeselftest", then resulttool should filter pairs based on OESELFTEST_METADATA appended to test configuration. If metadata is absent from test results, in order to keep compatibility with older results, add a "guessing" mechanism to generate the missing OESELFTEST_METADATA. The guessed data is tightly coupled to the autobuilder configuration, where all oe-selftest executions are described (From OE-Core rev: 94ab7c2b892bf292dd86619ca9c63ddd7bf53f3c) Signed-off-by: Alexis Lothoré Signed-off-by: Richard Purdie

scripts/resulttool/regression: remove unused import

2023-02-26T11:59:52+00:00

(From OE-Core rev: 4d6a74fcee1479562bf66360f20d528107c70887) Signed-off-by: Alexis Lothoré Signed-off-by: Richard Purdie

scripts/oe-selftest: append metadata to tests results

2023-02-26T11:59:52+00:00

Many stored results TEST_TYPE are set to "oeselftest", however all those tests are not run with the same sets of parameters, so those tests results may not be comparable. Attach relevant parameters as tests metadata to allow identifying tests configuration so we can compare tests only when they are run with the same parameters. (From OE-Core rev: 406ec0a87e80d1ee0dd1d246adfe9507c10450ff) Signed-off-by: Alexis Lothoré Signed-off-by: Richard Purdie

bitbake: documentation: bitbake: add file-checksums to varflags section

2023-02-26T11:49:41+00:00

Fixes [YOCTO #11605] by: - Adding definition of file-checksums to Variable Flags section. - Describe data to add to list which adds external file dependencies. - Write example on usage to prepend a value to file-checksums list. (Bitbake rev: 6bc65e6402a74c9a65e29333a7e0f1f85dcbcf58) Signed-off-by: Richard Elberger Signed-off-by: Richard Purdie

bitbake: fetch/npmsw: add more short forms for git operations

2023-02-26T11:49:41+00:00

>From the npm-install documentation [1] the CLI provides a set of short forms when the install fetches from git. These include "github:" example: npm install github:mygithubuser/myproject "gist:" example: npm install gist:101a11beef "gitlab:" example: npm install gitlab:mygitlabuser/myproject "bitbucket:" example: npm install bitbucket:mybitbucketuser/myproject Commit 1d8af6aed0a9 [fetch2: npmsw: Add support for github prefix in npm shrinkwrap version] by Stefan Herbrechtsmeier added support for the "github:" but the others would marked as 'Unsupported dependency'. The other prefixes are added in this commit, along with extending the tests to cover some of these. However, there is one more short form for github which npm-install allows which forgoes the prefix altogether. example: npm install mygithubuser/myproject Unfortunately this format is a bit problematic as it lacks any easily identifiable 'marker' to match against, and it could be either the github short form or install from folder format. Experimentation shows that the folder format requires a leading './' or '/', so we use this to rule out the ambiguity. If this approach to folder and github formats disambiguation is incorrect it won't matter anyways as the folder format is unrecognized by the code as-is and thus with this change or without, things would fail. Since we have to be less strict in the check for git operations we move it to be the last install format which we check, such that the less ambiguous formats can be sorted out first. [1] https://docs.npmjs.com/cli/v9/commands/npm-install [Yocto #14236] (Bitbake rev: 0ac6f6cb5d807919ed13a8b7bb3fb551b79c5a71) Signed-off-by: Mark Asselstine Signed-off-by: Richard Purdie

bitbake: gitsm: Fix path construction for relative submodule URI

2023-02-26T11:49:41+00:00

The submodule repository URI contains a path to something not necessarily on the local filesystem. This means that we can't use realpath to normalise it without risking getting bad results if the path happens to match something on the local filesystem. This situation can cause very confusing errors if that matching local path happens to be a symlink to somewhere else. Using normpath rather than realpath means that the path simplification follows simple rules on the string rather than looking at the local filesystem and avoids problems. (Bitbake rev: 47b271e6c8d96960ebe70f80e58f30cc4cbf42e1) Signed-off-by: Mike Crowe Co-authored-by: Dave Craig Signed-off-by: Richard Purdie