On Tue, 15 Oct 2024 at 22:32, Richard Purdie <[email protected]> wrote: > > So that's the tricky thing for us. We will have to run the script at > > a time window where no builds are happening. Because when I tried > > deleting corrupted objects from the s3 sstate cache manually, the > > corrupted sstate object ended up being reuploaded by ongoing > > builds... And this is pretty difficult to execute reliably, since we > > have so many builds. > > I'm a little bit puzzled here. How would something upload the corrupt > artefact back into the system?
I am also puzzled by this. I was going to suggest that perhaps there's a rare bug in zstd compressor that deterministically (and reproducibly) creates a corrupt archive on a certain input, because ongoing builds can't simply 'reupload' something corrupted that has been deleted from sstate. But maybe there's some extra proprietary layer of 'overwriting' and 'synchronization' where all this trouble is coming from. Alex
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#205946): https://lists.openembedded.org/g/openembedded-core/message/205946 Mute This Topic: https://lists.openembedded.org/mt/108828269/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
