From: Fabio Berton <fbberton@gmail.com>
To: openembedded-core@lists.openembedded.org
Cc: richard.purdie@linuxfoundation.org
Subject: Re: [OE-core] [PATCH] buildhistory.bbclass: restore BUILDHISTORY_PRESERVE files
Date: Wed, 25 Jun 2025 11:26:49 +0100 [thread overview]
Message-ID: <12213779-fcd9-4091-b340-44eb200bc97f@gmail.com> (raw)
In-Reply-To: <089b2ea3388321570537e1f7adef3a24efe3250e.camel@linuxfoundation.org>
Hi Richard,
Thanks for looking into this. I was wondering if there is a way to know whether BUILDHISTORY_PRESERVE, or another variable, is not intended to be part of the end user API?
Regards,
Fabio
On 6/23/25 21:48, Richard Purdie via lists.openembedded.org wrote:
> On Wed, 2025-01-15 at 15:31 +0000, Pedro Ferreira via lists.openembedded.org wrote:
>> From: Pedro Ferreira <Pedro.Silva.Ferreira@criticaltechworks.com>
>>
>> On each build using sstate-cache, buildhistory will move
>> content to a temporary folder named `old`.
>> When buildhistory looks for the main dir, it wont find it
>> and ends up creating it.
>> As a consequence how code is structured wont restore any
>> preserved file.
>>
>> Code block moved to ensure if old dir exists, it will
>> attempt to restore those files marked to preserve.
>>
>> Signed-off-by: Pedro Silva Ferreira <Pedro.Silva.Ferreira@criticaltechworks.com>
>> ---
>> meta/classes/buildhistory.bbclass | 15 +++++++--------
>> 1 file changed, 7 insertions(+), 8 deletions(-)
>
> I spent a lot of time on Friday looking at this. The BUILDHISTORY_RESET
> code path is horrible to understand and basically just hacked into na
> don top of the rest of the system. BUILDHISTORY_PRESERVE was never
> really intended as a end user API either.
>
> After much consideration, I've sent a patch proposing we remove support
> for BUILDHISTORY_RESET. I think the behaviour would be better coded
> into the CI integration in different cases.
>
> If we do want in tree support for this "reset" functionality, it needs
> to be written in a way where the code can be understood and it needs to
> have test cases. It would also need documentation as these code paths
> are currently undocumented.
>
> As Ross previously mentioned the interaction with an sstate cache is
> also horrible and is another reason I think it is safer for the user to
> do what they want/need CI side rather than in the class code. Sorry it
> has taken as long to work all this out, the code really is hard to
> unravel.
>
> Cheers,
>
> Richard
>
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#219219): https://lists.openembedded.org/g/openembedded-core/message/219219
> Mute This Topic: https://lists.openembedded.org/mt/110629321/6083838
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [fbberton@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
next prev parent reply other threads:[~2025-06-25 10:26 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-15 15:31 [PATCH] buildhistory.bbclass: restore BUILDHISTORY_PRESERVE files Pedro Ferreira
2025-01-22 13:42 ` [OE-core] " Ross Burton
2025-01-23 14:37 ` Pedro Ferreira
2025-03-06 14:26 ` Pedro Ferreira
2025-03-12 13:40 ` [OE-core] " Ross Burton
2025-06-23 20:48 ` Richard Purdie
2025-06-25 10:26 ` Fabio Berton [this message]
2025-06-25 10:46 ` Richard Purdie
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=12213779-fcd9-4091-b340-44eb200bc97f@gmail.com \
--to=fbberton@gmail.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=richard.purdie@linuxfoundation.org \
/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