meta/conf: Start to populate autobuilder config fragments

This populates the fragments directory with:

a) the default set of variables used in all autobuilder builds
b) three different multilib test configurations used by the autobuilder

The aim here is to start to make some of the autobuilder configuration more
visable and patchable by users, and to allow some test confiturations to
be user selectable if appropriate and needed for debugging.

The main aautobuilder fragment is probably not directly reusable by most
users, it contains the resource limits as used on the autobuilder itself. I
can see arguments both way for whether this should be included in OE-Core or not
but having an example of how we configure this is probably useful.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
 .../yocto-autobuilder/autobuilder.conf        | 35 +++++++++++++++++++
 .../multilib-mips64-n32.conf                  |  8 +++++
 .../yocto-autobuilder/multilib-x86-lib32.conf |  6 ++++
 .../yocto-autobuilder/multilib-x86-lib64.conf |  6 ++++
 4 files changed, 55 insertions(+)
 create mode 100644 meta/conf/fragments/yocto-autobuilder/autobuilder.conf
 create mode 100644 meta/conf/fragments/yocto-autobuilder/multilib-mips64-n32.conf
 create mode 100644 meta/conf/fragments/yocto-autobuilder/multilib-x86-lib32.conf
 create mode 100644 meta/conf/fragments/yocto-autobuilder/multilib-x86-lib64.conf

On Mon, 24 Mar 2025 at 18:09, Richard Purdie via
lists.openembedded.org
<richard.purdie=linuxfoundation.org@lists.openembedded.org> wrote:
>
> This populates the fragments directory with:
>
> a) the default set of variables used in all autobuilder builds
> b) three different multilib test configurations used by the autobuilder
>
> The aim here is to start to make some of the autobuilder configuration more
> visable and patchable by users, and to allow some test confiturations to
> be user selectable if appropriate and needed for debugging.
>
> The main aautobuilder fragment is probably not directly reusable by most
> users, it contains the resource limits as used on the autobuilder itself. I
> can see arguments both way for whether this should be included in OE-Core or not
> but having an example of how we configure this is probably useful.

I'm glad to see fragments taken into use in one of the most core
places in yocto :)

There are a few notes I'd like to make:

- there's a companion patch to yocto-autobuilder-helper that should be
posted too:
https://git.yoctoproject.org/yocto-autobuilder-helper/commit/?h=master-next&id=accad467ff54ed71a00a1a97ad015195101dd4c2

- that patch keeps "BB_HASHSERVE = '${AUTOBUILDER_HASHSERV}'" in
config.json and doesn't move it to the fragment, that should be
explained.

- the new autobuilder.conf inherits from config.json a variety of
things in addition to build host resource usage. It also has SDK
settings, logging/reporting settings, qemu/testimage settings, unsets
sanity tested distros etc. As a followup, I'd like to structure and
split this up to different fragments under
conf/fragments/yocto-autobuilder/. Some of it could probably move to
poky, so that the delta between what poky users build and what
autobuilder builds is as minimal as possible, and ideally non-existent
(e.g. the difference is only in resource limits and directory/url
settings). All such tweaks should be done in lockstep with changes to
config.json or meta-poky/ to reflect them. And they must take into
account the history of config.json changes, e.g. consider why
something was added to begin with, and whether it is still needed.
It's a lot of delicate work, but I think it's worth doing (I can find
time for it).

Alex

On Mon, 2025-03-24 at 19:28 +0100, Alexander Kanavin wrote:
> On Mon, 24 Mar 2025 at 18:09, Richard Purdie via
> lists.openembedded.org
> <richard.purdie=linuxfoundation.org@lists.openembedded.org> wrote:
> > 
> > This populates the fragments directory with:
> > 
> > a) the default set of variables used in all autobuilder builds
> > b) three different multilib test configurations used by the autobuilder
> > 
> > The aim here is to start to make some of the autobuilder configuration more
> > visable and patchable by users, and to allow some test confiturations to
> > be user selectable if appropriate and needed for debugging.
> > 
> > The main aautobuilder fragment is probably not directly reusable by most
> > users, it contains the resource limits as used on the autobuilder itself. I
> > can see arguments both way for whether this should be included in OE-Core or not
> > but having an example of how we configure this is probably useful.
> 
> I'm glad to see fragments taken into use in one of the most core
> places in yocto :)
> 
> There are a few notes I'd like to make:
> 
> - there's a companion patch to yocto-autobuilder-helper that should be
> posted too:
> https://git.yoctoproject.org/yocto-autobuilder-helper/commit/?h=master-next&id=accad467ff54ed71a00a1a97ad015195101dd4c2

Well, I knew this was going to get rejected so I didn't think it worth
posting yet.

> 
> - that patch keeps "BB_HASHSERVE = '${AUTOBUILDER_HASHSERV}'" in
> config.json and doesn't move it to the fragment, that should be
> explained.

Right, there are multiple reasons for that, not least that the
autobuilder has access to servers in a different way to any other place
so it can write data to that server. Those settings won't work anywhere
else at all. There are also cases in the configuration where we need to
avoid setting or change that, not least when we had two different
clusters running from the same config with different write locations.
It was therefore set from local worker specific overrides.

This can probably be simplified again in future. I was trying to
experiment with what we could move out and start working with, not
least to use the fragments feature.

> - the new autobuilder.conf inherits from config.json a variety of
> things in addition to build host resource usage. It also has SDK
> settings, logging/reporting settings, qemu/testimage settings, unsets
> sanity tested distros etc. As a followup, I'd like to structure and
> split this up to different fragments under
> conf/fragments/yocto-autobuilder/. Some of it could probably move to
> poky, so that the delta between what poky users build and what
> autobuilder builds is as minimal as possible, and ideally non-existent
> (e.g. the difference is only in resource limits and directory/url
> settings). All such tweaks should be done in lockstep with changes to
> config.json or meta-poky/ to reflect them. And they must take into
> account the history of config.json changes, e.g. consider why
> something was added to begin with, and whether it is still needed.
> It's a lot of delicate work, but I think it's worth doing (I can find
> time for it).

I'm not sure I 100% agree.

We're after to expose what the autobuilder is setting and this does so
in one relatively clear fragment. If we start splitting it up, users
then need to mentally combine all the different pieces in order to see
what the autobuilder is using.

The key question is whether any of the fragments are more usable in
isolation and whether the naming would make sense of it. I guess where
I worry is the number of fragments you hint at above.

I can see the case for these being separated out:

QEMU_USE_KVM = 'True'
INHERIT += 'report-error'
PREMIRRORS = ''
BB_GENERATE_MIRROR_TARBALLS = '1'
IMAGE_CLASSES += 'testimage'
SANITY_TESTED_DISTROS = ''
SDK_EXT_TYPE = 'minimal'
SDK_INCLUDE_TOOLCHAIN = '1'
ESDK_LOCALCONF_REMOVE:append = 'BB_HASHSERVE'
SDK_TOOLCHAIN_LANGS += 'rust'

with the remainder being "resource" constraints. I'm not sure I'd want
to separate them more than that.

As you say, some of this could potentially move to poky, although I've
been trying hard not to reduce the differences between nodistro and
poky rather than increase them, so the case may be for changing
nodistro, which is a different level of work.

I also realise we could have one fragment including a list of
fragments. I just worry that if we split this up too much, one of the
objectives of showing people the autobuilder config easily gets lost.
The amount I get asked that is scary.

FWIW even getting to the point where I posted this patch was painful
due to tests failing due to the differing ordering in the config of
auto.conf vs fragments. The delicate work you mention above is fine, if
we share a common vision but I'm a bit worried we aren't entirely
aligned at present :/.

Cheers,

Richard

On Mon, 24 Mar 2025 at 23:03, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:

> FWIW even getting to the point where I posted this patch was painful
> due to tests failing due to the differing ordering in the config of
> auto.conf vs fragments. The delicate work you mention above is fine, if
> we share a common vision but I'm a bit worried we aren't entirely
> aligned at present :/.

I think we can actually agree. Here's a proposal:

- the resource limiting and timeout tweaks go to
autobuilder-resources.conf, everything else stays in autobuilder.conf.
No further fragments are added.

- later, over time, with care, things in autobuilder.conf should be:
-- explained via #-comments from config.json commit history (json
didn't allow this, and the whole set became disjointed and
undocumented, and at the same time deviating from standard poky or
core)
-- moved to core or poky config where that makes sense.

Alex

Hi Richard,

On Mon Mar 24, 2025 at 6:09 PM CET, Richard Purdie via lists.openembedded.org wrote:
[...]
> +SANITY_TESTED_DISTROS = ''

Will the recent 'removevars' addition from the helper's scripts/setup-config
still work after that change?

Antonin

On Tue, 2025-03-25 at 09:58 +0100, Antonin Godard wrote:
> Hi Richard,
> 
> On Mon Mar 24, 2025 at 6:09 PM CET, Richard Purdie via
> lists.openembedded.org wrote:
> [...]
> > +SANITY_TESTED_DISTROS = ''
> 
> Will the recent 'removevars' addition from the helper's
> scripts/setup-config still work after that change?

Well spotted. No, it probably won't :/

Cheers,

Richard