Hi I am also hitting this wall. Any reason why the original patches could not be merged?
On Fri, Nov 29, 2019 at 5:49 PM Martin Jansa <[email protected]> wrote: > > On Wed, Aug 30, 2017 at 9:54 AM Martin Jansa <[email protected]> wrote: >> >> I agree with this patchset and it would be OK with IGNORE_SETSCENE_ERRORS >> conditional as well. >> >> We're also sometimes seeing these errors, sometime anticipated when cleaning >> shared sstate-cache on NFS server sometimes unexpected when NFS or network >> goes down for a minute and for some builds it happens between >> sstate_checkhashes() and using the sstate. >> >> We normally stop all jenkins builds, until the cleanup is complete (there is >> jenkins job doing the cleanup, so it puts jenkins into stop mode, waits for >> all current jobs to finish which can take hours, then performs the cleanup >> and cancels the stop mode), but we cannot stop hundreds of developers using >> the same sstate-cache in local builds (especially when we cannot really know >> when exactly the job will have free jenkins to perform the cleanup) - >> luckily in local builds it doesn't hurt so bad, because the developers are >> more likely to ignore the error as long as the image was created, but in >> jenkins builds when bitbake returns error we cannot easily distinguish this >> case of "RP is intentionally warning us that something went wrong with >> sstate, but everything was built correctly in the end" and "something failed >> in the build and we weren't able to recover from that, maybe even the image >> wasn't created" - so we don't trigger the follow up actions like announcing >> new official builds or parsing release notes or automated testing. >> >> Yes we could add more logic to these CI jobs, to grep the logs to decide if >> this error was the only one which caused the bitbake to return error code >> and ignore the returned error in such case, but simple variable is easier to >> maintain (even for the cost of forking bitbake and oe-core) and will work >> for local builds as well. > > > I was using these 2 changes in my fork of oe-core and bitbake since they > were sent to the list, but today after getting a bunch of errors like this > from build which unfortunately wasn't using my forks and few questions about > why these errors aren't ignored from fellow developers I've finally found > time to improve our CI jobs to deal with this and ignore the bitbake return > code if it's reporting failure only because of these setscene fetcher > failures. > > If someone needs similar work around for bitbake behavior, here is what I did: > https://github.com/webOS-ports/jenkins-jobs/pull/12 > yes, it's ugly, but it seems to work and is a bit better than forking oe-core > and bitbake just because of this issue. > > Regards, > -- > _______________________________________________ > Openembedded-core mailing list > [email protected] > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- Ricardo Ribalda -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
