From: "Moessbauer, Felix" <felix.moessbauer@siemens.com>
To: Anton Mikanovich <amikan@ilbers.de>,
"isar-users@googlegroups.com" <isar-users@googlegroups.com>
Subject: RE: [RFC] add uuid to schroot folder
Date: Tue, 12 Jul 2022 13:38:27 +0000 [thread overview]
Message-ID: <AM9PR10MB4869B00B60DC28C75A69D39A89869@AM9PR10MB4869.EURPRD10.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <3bdafbaf-2ed9-46a4-3606-46ac76f99731@ilbers.de>
> From: Anton Mikanovich <amikan@ilbers.de>
> Sent: Monday, July 11, 2022 8:35 PM
> To: isar-users@googlegroups.com; Moessbauer, Felix (T CED SES-DE) <felix.moessbauer@siemens.com>
> Subject: Re: [RFC] add uuid to schroot folder
>
> 11.07.2022 21:31, Anton Mikanovich wrote:
> PIDs are not unique across containers.
> When running the build in a container (e.g. the kas container),
> the PID of bitbake is likely the same across multiple simultaneously
> running builds.
>
> This is especially the case for CI runners, where it is common that
> multiple jobs run in parallel.
>
> This patch adds an additional UUID component stored till the end of
> the build in bitbake persistend storage.
>
> Signed-off-by: Anton Mikanovich mailto:amikan@ilbers.de
> Signed-off-by: Felix Moessbauer mailto:felix.moessbauer@siemens.com
> Here is the version I propose as an alternative to original patch.
> Main differences are:
> 1) placing everything inside bitbake
I tried that as well but failed at writing the code in a way that BB does not complain about non-deterministic metadata.
If that works, your solution is much better.
Felix
> 2) regeneration of UUID on every bitbake run
next prev parent reply other threads:[~2022-07-12 13:38 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-11 18:31 Anton Mikanovich
2022-07-11 18:34 ` Anton Mikanovich
2022-07-12 13:38 ` Moessbauer, Felix [this message]
2022-07-13 13:23 ` Anton Mikanovich
2022-07-13 13:52 ` Moessbauer, Felix
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AM9PR10MB4869B00B60DC28C75A69D39A89869@AM9PR10MB4869.EURPRD10.PROD.OUTLOOK.COM \
--to=felix.moessbauer@siemens.com \
--cc=amikan@ilbers.de \
--cc=isar-users@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox