Add an argument parser so that the use of the cache or verbose logging
can be enabled/disabled without having to edit the source code.
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This script generates sorting keys so that 20240201-4 sorts before 20240201-20,
but the code assumes that there is only one hyphen when it splits.
However, there is now a patchstatus-meta-oe directory, which causes the
script to throw an exception.
Before padding, use a regex to check that the key is of the format we expect,
that is two integers separated by a hyphen.
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This report visualises the AB-INT bugs over time, to help find trends
such as bugs which are no longer occuring, or bugs which should be fixed
urgently.
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add meta-exein yocto-check-layer testing. Due to HOSTTOOLS issues, we
need to had a horrible hack. v2 compatibility doesn't test for HOSTTOOLS
changes although perhaps the next version might.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is useful when using large sets of layers to
verify that the right layers have been added in
the right order.
Signed-off-by: Ross Burton <ross.burton@arm.com>
Extract the logging of auto.conf to a new log_file_contents() function,
and instead of calling it before _every_ call of bitbake, only show it when
actually writing the auto.conf.
Signed-off-by: Ross Burton <ross.burton@arm.com>
It is often helpful to know how many CVEs are open against a given recipe.
Add a summary table of this to the end of the CVE listing.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add a dry-run mode to be able to run send_qa_email locally but disabling
any output (no commit or tag pushed upstream, no mail sent). This eases
all release-related debugging. This dry-run mode is enabled by the
following changes:
- add a -d/--dry-run parameter to send_qa_email
- update test_results url to allow cloning test_results repository without
having its public key registered upstream
- skip test results storage
- do not erase test results temp dir
- skip email sending (but still generate it)
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
generate_regression_reports is currently protect in a try/catch block to
prevent it from canceling QA email generation when encountering an issue,
but get_regression_base_and_target is not.
Make sure that get_regression_base_and_target can not prevent QA email from
being generated by adding it to the try/catch block protecting
send_qa_email. While doing so, make sure to preserve the exitcode variable
to make sure that the step is still marked as fail in autobuilder to make
sure the error does not go silent. However the variable is not needed as
global anymore since it is now used in a single function.
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
send_qa_email currently fails when dealing with release version starting a
new major, for example 5.0. This has been observed for example when trying
to generate 5.0_M1.rc1
This specific versioning makes previous tag computation method fall through
last branch which currently expects that the current release tag indeed
exists (5.0_M1), which is true when checking regression reports a
posteriori, but not in an autobuilder run (tag is added only when the
release has been "validated")
Fix tag computation for this case by getting previous release tag with git
ls-remote, instead of relying on git describe with a possibly non-existing
tag. While doing so, add a few tests about this specific case.
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
send_qa_email currently deals with tags in a "reproducible" way: despite
new versions being released on different branches, the computation of the
"reference" version for a specific input version always remain the same.
This behavior does not match perfectly real expectations: if at the some
point we get version 4.3.1 as a comparison reference for a regression
report, and 4.3.2 is released some time later, we want the next comparision
to be done against 4.3.2.
Start introducing this new behavior by allowing the tests to check returned
version against regex patterns instead of static strings, so we can for
example use wildcards on the "micro" version
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use intermediate variables for test input/output, and print expected
output in subtest to get more info when a test fails
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Update run-toaster-test to include BUILDDIR and TOASTER_TEST_USE_SSTATE_MIRROR which will be use in the build test in toaster
Signed-off-by: Marlon Rodriguez Garcia <marlon.rodriguez-garcia@savoirfairelinux.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Strip quotes from directory variables as they caused path errors.
Add environment variable for the toaster artifact directory.
Migrate from tox and django tools to using pytest.
Install python module requirements from the script as this is no
longer handled by tox.
Signed-off-by: Alexander Lussier-Cullen <alexander.lussier-cullen@savoirfairelinux.com>
CC: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Pass the toaster test environment SSTATE_DIR and DL_DIR for faster
builds and TOASTER_DJANGO_TMPDIR to remove problematic temp files
from the root level '/tmp' directory.
Signed-off-by: Alexander Lussier-Cullen <alexander.lussier-cullen@savoirfairelinux.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Sort versions as if we used semantic versioning.
Include updates for the 4.3 release as well.
Signed-off-by: Michael Halstead <mhalstead@linuxfoundation.org>
Add a runner that installs the patchtest dependencies in a Python venv
and then starts patchtest's selftests.
Signed-off-by: Trevor Gamblin <tgamblin@baylibre.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add a toaster test builder that runs the tox test suite using a new
run-toaster-tests script.
Signed-off-by: Alexander Lussier-Cullen <alexander.lussier-cullen@savoirfairelinux.com>
CC: richard.purdie@linuxfoundation.org
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Do another git-pull in the metrics repository before updating the
metrics, in case other metrics jobs running in parallel have updated the
repositories since they were cloned. There will always be possibility
of racing metrics jobs, but this should reduce the chance of it
happening.
An alternative would be to commit and then rebase before pushing, but I
fear that a git-merge could produce invalid JSON and we'd have to
manually fix up the repository. In my opinion, a wasted metrics run is
preferable to potentially corrupted repositories.
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Do another git-pull in the metrics repository before updating the
metrics, in case other metrics jobs running in parallel have updated the
repositories since they were cloned. There will always be possibility
of racing metrics jobs, but this should reduce the chance of it
happening.
An alternative would be to commit and then rebase before pushing, but I
fear that a git-merge could produce invalid JSON and we'd have to
manually fix up the repository. In my opinion, a wasted metrics run is
preferable to potentially corrupted repositories.
[RP: Moved to after the bitbke invocation]
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
setup-auh and run-auh were doing what the AB config.json does:
* creating repo checkouts: Now use NEEDREPOS
* configuring bitbake env: Now use extravars
This refactoring is needed to prepare adding AUH meta-oe support.
Signed-off-by: Yoann Congal <yoann.congal@smile.fr>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Rewrite the scripts that gather the metrics to be more generic.
Extract the metrics repository cloning out so that we don't have to
repeatedly clone it.
Make the scripts parse their arguments using getopt and be more specific
about what they're passed. In particular, this means that for the patch
review run we pass the _repository_ that we're scanning so we can do git
operations on it, and the base of the _layers_ (either a layer, or a
directory containing layers) so we know what to scan.
Be more clever when identifying what commits we need to analyse for
patch review: instead of iterating through a set randomly, we can keep
the revision list sorted and the checkout operations are a lot faster.
Remove the commit/file count metric addition as patchreview itself does
that now.
Add an explicit --push option so it's easy to test the scripts in
isolation without pushing.
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is a handy helper script to query the Buildbot REST API to
create a list of Yocto Project Compatible 2.0 layers, as defined by
successful running of the "check-layers*" jobs.
The script only considers the 'jobs' ("Builders" in Buildbot speak) you
ask it to query.
The script looks at the latest -n successful builds for a branch that
matches from a list. The number of builds approach was used because
the property_list cannot be queried for "branch" in the "builders" API.
It looks for a "step" name pattern via a regex, with which all currently
running "check-layer" and "check-layer-nightly" jobs conform.
Once a branch has successfully been queried, it is removed from the list
in further iterations. The intent is to only find the latest passing
list of compatible layers, for each branch.
The output is a yp_compatible_layers.json file which can
be pretty printed with:
cat yp_compatible_layers.json | jq
Signed-off-by: Tim Orling <tim.orling@konsulko.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Rather than running multiple checkouts, lets move this to the autobuilder
to handle and have it trigger the builds with the right checkouts.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We only monitor the master branch for patch metrics as we can't really make
improvements to release branches.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
To prepare for splitting things up, only clone the metrics repo if it isn't present.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It has been observed that some regression reports generation may failed
when the comparision base is a branch (e.g master) because we can not find
any test results associated to the branch HEAD. This is especially true for
branches which often change, because not all revisions on those branch are
subject to CI tests.
To fix that, whenever we are not dealing with a release, parse the latest
tested revision in test results repository on target branch in order to
guess the corresponding revision in poky repository, so we are sure that
revisions passed to yocto_testresults_query are indeed tested and
regression report can be generated
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Test results repository url is used at least twice, so define a constant
holding the url instead of hardcoding it multiple times
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There are some inversions in words used to describe elements of comparison
for regression reporting: the main function of send_qa_email starts using
"base" to talk about the target revision and "compare" to talk about the
reference against which it is compared. Then later in the script, the
"base" is used as "base of comparison"/reference revision, while the
"target" branch/revision appears. This becomes quite confusing when we need
to update the script
Re-align wording to avoid confusion:
- always use "target" to talk about current branch/revision of interest
(the newest)
- always use "base" to talk about the reference branch/revision (the
oldest), against which we want to compare the target revision
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Whilst the script needs to continue if we fail to generate a regression report,
set the exit code accordingly so our CI can flag the issue.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It is hard to tell which section of the code specific error messages
come from at present. Add more headers to the output so we can at
least tell which section the messages are from. It also adds some
timing information.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
