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>
It has been observed that when a new release branch is created, it is quite
easy to forget to update the BUILD_HISTORY_DIRECTPUSH variable, which leads
to failures in autobuilder like test results not being pushed.
Replace the BUILD_HISTORY_DIRECTPUSH usage with a hardcoded condition which
validates any branch in poky representing a "main" branch, i.e all branches
not ending in "-next"
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Instead of only generating regressions reports against HEAD of relevant branch, compute
most relevant tag (ie : release) against which we can check for regressions. General rules
introduced are the following :
- milestone release is checked against previous milestone if possible, otherwise
against major release
- point release is checked against previous point release if possible,
otherwise against major release
- major release is checked against previous major release
- a non release build is checked against base branch
Examples :
- 4.1.2.rc1 is checked against yocto-4.1.1
- 4.1.2 is checked against yocto-4.1.1
- 4.1.1.rc1 is checked against yocto-4.1
- 4.1.1 is checked against yocto-4.1
- 4.1 is checked against yocto-4.0
- 4.1.rc4 is checked against yocto-4.0
- 4.1_M2.rc1 is checked against 4.1_M1
- 4.1_M2 is checked against 4.1_M1
- 4.1_M1.rc1 is checked against yocto-4.0
- 4.1_M1 is checked against yocto-4.0
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The depth code doesn't work if the branch doesn't exist in the main repo
mirror and only the remote.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
By not syncing all the history is is possible to save some time/space
in the checkout process since we never use this data. This reduces data
from 650MB to 400MB or with the tarball, 416MB to 55MB.
The logic for the commands needs to be tweaked to handle this and as
written it can't work in non-HEAD revision case but that isn't a commonly
used situation.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The default behavior is to look for a bitbake command,
which fails and produces a confusing output of [-1:].
[YOCTO #14208]
Signed-off-by: Yi Fan Yu <yifan.yu@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This code was copy/pasted but in this case the variables should
be called "compare", not base.
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There are several issues:
* New branches don't currently have git regression history
* The regression tool errors if there isn't anything to compare against
To fix this, create a branch with history and only generate a regression
report if there are commits to compare against.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently there was no way to override an existing extra vars
assignment, which meant BB_NUMBER_THREADS was impossible to change.
This adds code to allow the higher override of a value to override
the other settings which makes the code function more as a user
would expect.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
[RP: Minor tweaks made to adpat to buildbot and option naming
Fixed shared-repo-unpack for publishing when no cache-dir supplied]
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Remove the code disabling it
* Move to a non-shared directory by default (but still support absolute pathnames
if wanted)
* Use shallow clones by default for speed
* Allow force pushing 'fork' mode branches
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Usage is documented in README and an example, local-example.json is
included.
Also clean up the parameter to loadconfig() as its actually not needed.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We want to be able to use data expansion/variable substitution
in most variables so convert to use the utils API for this.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The code clearly won't scale without some kind of variable substitution/
variable expansion mechanism, so add one.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
