Testing builds often run on branches <someone>/master[-next]. In these
cases we are really testing "master", so return that. Instead of
exiting with: "Release <future release> does not exist".
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We considered the next release to be active, but failed to include the
next release's milestones.
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Very useful for eg Old Milstone where you can then sort it by owner.
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is a a little script I have that should be somewhere public. It
simply lists all of the connected workers, but is very useful when used
in conjunction with parallel-ssh to run commands on every worker at once.
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We need buildtools (and the poky repo) for resulttool in some indexing steps. We don't
want buildtools in the dashboard step as we need semver from the host.
Rework the config to allow this and fix failures on the infrastructure.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
METADATA_BRANCH is the only way for us to check whether we're on master.
Check this variable first, and return the value of
LAYERSERIES_COMPAT_core if we're not on master.
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Using METADATA_BRANCH is less accurate than getting the current release
from LAYERSERIES_COMPAT_core, which should always be equal to the
release we want to compare for.
The code the exit if the current release was not found is left there
just in case.
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Add a replacement for the the existing Bug Triage page on the wiki[1].
This uses client-side JavaScript to parse the releases.json and query
Bugzilla, so shouldn't need updating very often.
[1] https://wiki.yoctoproject.org/wiki/Bug_Triage
Signed-off-by: Ross Burton <ross.burton@arm.com>
Add a stable_release boolean argument to _compare(). If True just
ignore missing workers on the AB, because we want to keep the full list
of tested releases in poky.conf for stable branches.
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
On older releases the bitbake server output is confusing the script.
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add a check of the fixture data to try and ensure we don't release with
incorrect configuration for toaster.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It would be useful to know the list of releases in each release series
so add this information to releases.json. Also add milestone informaiton
for the current development branch.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For autobuilder use, it will be more helpful to print warnings for the issues found
which will show up in the autobuilder UI in this format. We can then save the error
exit code for actual script failures which should improve usability from the autobuilder
perspective.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add scripts/yocto-supported-distros to either:
- List the supported distros on the autobuilder (prints the workers for
one or more release).
- With --compare, get the supported distro from poky.conf
(SANITY_TESTED_DISTROS), mangle the worker names to make them match the
lsb_release distro strings, and return 1 in case of difference (and
print the differences). Return 0 in case of 1 to 1 match.
The aim of this script is to make maintaining the poky.conf file and the
workers easier.
The release-from-env flag can be used to get the current release from
METADATA_BRANCH.
The --config-from-web flag can be used to get the current autobuilder
config.py by fetching it from the web repo.
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
rsvg-convert, which we use to convert SVG images to PDFs/PNGs, would
always print out the following error:
Fontconfig error: Cannot load default config file: No such file: (null)
As a result some SVGs are oddly rendered because it doesn't find the
correct fonts.
This can be easily fixed by setting and exporting the FONTCONFIG_PATH
variable which must point to a directory containing a fonts.conf file.
Since we build on multiple distros, we may not always find this file in
/etc/fonts (installed there by default on many distros). Additionally,
we can also install custom fonts using tlmgr and use them thanks to that
file.
Add a custom fonts.conf that adds /texlive/texmf-dist/fonts to the list
of directories to look for fonts. This files is just based on the
original fonts.conf. Also add the nimbus15 package to the list of tlmgr
installed packages so that we make sure we always use the same font for
rendering images (assuming the SVG files use the "Nimbus Sans L" font).
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
On https://www.yoctoproject.org/development/releases, the "Full Release
List" can mislead users into thinking the list represents all of the
Yocto release, whereas these are only EOL releases. Remove this list and
merge everything in "Previous Release List".
[YOCTO #15339]
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
We were using this one temporarily to use the new Sphinx version and
rsvg-tools. Update the URL now that 5.1.1 is released.
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
