RE: ISAR schroot mountpoints when running in container

["Moessbauer, Felix" <felix.moessbauer@siemens.com>]

> -----Original Message-----
> From: Anton Mikanovich <amikan@ilbers.de>
> Sent: Friday, July 1, 2022 2:09 PM
> To: Moessbauer, Felix (T CED SES-DE) <felix.moessbauer@siemens.com>; isar-
> users@googlegroups.com
> Cc: Kiszka, Jan (T CED) <jan.kiszka@siemens.com>; Bezdeka, Florian (T CED SES-
> DE) <florian.bezdeka@siemens.com>; ubely@ilbers.de; Schmidt, Adriaan (T CED
> SES-DE) <adriaan.schmidt@siemens.com>
> Subject: Re: ISAR schroot mountpoints when running in container
> 
> 01.07.2022 14:30, Moessbauer, Felix wrote:
> > Required changes:
> >
> > In ISAR, we have to make the name of the Schroot folder more unique. But as
> BB requires recipes to be deterministic (per-build), we have to inject the ID from
> the outside. This could happen either via local.conf or via an env-var. This env-
> var has to be provided by KAS, with an fallback in ISAR to use the PID of the
> bitbake process if not provided.
> >
> > A probably better strategy would be to get a per-bitbake invocation constant
> UUID directly from Bitbake. Don't know if that already exists in BB.
> > Putting Adriaan in CC.
> >
> > Felix
> 
> Hello, I've already proposed unique per-build ID generation in '[PATCH 2/6] base:
> Implement bitbake build ID'.
> Not sure it suits mentioned requirements, but can be good starting point.

Just had a look at the patch. That should also work, but only if the date / time information is valid.
In some environments which are used to test reproducible builds, date / time might be fixed or redacted.

I just sent out another approach that relies on an externally provided UUID.
Don't know which one is better.

Felix