On Thu, 20 Feb 2020 at 11:36, Richard Purdie <[email protected]> wrote: > > On Thu, 2020-02-20 at 11:26 +0000, Paul Barker wrote: > > In my new CI setup I'm using an sstate mirror which seems to have > > some > > occasional download issues. This results in the setscene task > > failing. > > For example: > > > > ERROR: qt3d-5.13.2+gitAUTOINC+93361f1a59-r0 > > do_package_write_ipk_setscene: Fetcher failure: Unable to find file > > file://fd/sstate:qt3d:armv7at2hf-neon-linux- > > gnueabi:5.13.2+gitAUTOINC+93361f1a59:r0:armv7at2hf- > > neon:3:fda6c3edff0205b07ff176cf16771247117fa310bc65a6a1df6befc4230e0a > > 74_package_write_ipk.tgz;downloadfilename=fd/sstate:qt3d:armv7at2hf- > > neon-linux-gnueabi:5.13.2+gitAUTOINC+93361f1a59:r0:armv7at2hf- > > neon:3:fda6c3edff0205b07ff176cf16771247117fa310bc65a6a1df6befc4230e0a > > 74_package_write_ipk.tgz > > anywhere. The paths that were searched were: > > /builds/SanCloudLtd/sancloud-arago/build/sstate-cache > > /builds/SanCloudLtd/sancloud-arago/build/sstate-cache > > ERROR: qt3d-5.13.2+gitAUTOINC+93361f1a59-r0 > > do_package_write_ipk_setscene: No suitable staging package found > > ERROR: Logfile of failure stored in: > > /builds/SanCloudLtd/sancloud-arago/build/tmp/work/armv7at2hf-neon- > > linux-gnueabi/qt3d/5.13.2+gitAUTOINC+93361f1a59- > > r0/temp/log.do_package_write_ipk_setscene.10524 > > NOTE: recipe qt3d-5.13.2+gitAUTOINC+93361f1a59-r0: task > > do_package_write_ipk_setscene: Failed > > WARNING: Setscene task > > (/builds/SanCloudLtd/sancloud-arago/sources/meta-qt5/recipes- > > qt/qt5/qt3d_git.bb:do_package_write_ipk_setscene) > > failed with exit code '1' - real task will be run instead > > > > As indicated in the final warning message there the real tasks run > > since no sstate artifact is available. These tasks succeed: > > > > NOTE: recipe qt3d-5.13.2+gitAUTOINC+93361f1a59-r0: task > > do_package_write_ipk: Succeeded > > > > The result is a successful build of the desired images. However, the > > build is marked as a failure due to those sstate errors: > > > > Summary: There were 11 ERROR messages shown, returning a non-zero > > exit code. > > > > Is this the expected behaviour? The final images are built correctly. > > I can't see any simple way to mask those setscene errors but I might > > be missing something. > > > > The full log can be seen at > > https://gitlab.com/SanCloudLtd/sancloud-arago/-/jobs/443901140/raw. > > I'm on the zeus branch here, I'll try to re-test on master later if I > > can. > > We've discussed this before and it can be argued either way. > > Personally, I worry about why artefacts "disappear" and this is why its > an error, files should not be disappearing part way through a build. > > From a bitbake perspective, a task really did fail and task failures > are errors. The fact it was able to recover is a bonus. > > Perhaps it should be a warning now we have levels of warnings that are > meaningful. Previously we threw so many, this would have been one more > lost amongst many. I know many people don't like the behaviour.
I'm now looking into this... In sstate_checkhashes() we mark sstate as available if fetcher.checkstatus() succeeds. Then at a later point sstate_setscene() calls sstate_installpkg() calls pstaging_fetch() calls fetcher.download() to actually get the sstate artifact. If the artifact is removed from the mirror between these two accesses (due to an sstate mirror clean up running in parallel to a build), or if there is an intermittent download failure we could see checkstatus() succeed then download() fail. I don't think we should ignore all setscene errors but in the specific case where it's the download step that fails I think that should be a warning. Or it could be an error by default with a variable we can set to turn it into a warning. Does that sound reasonable? If so I'll work up a patch. Thanks, Paul
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#48530): https://lists.yoctoproject.org/g/yocto/message/48530 Mute This Topic: https://lists.yoctoproject.org/mt/71426351/21656 Group Owner: [email protected] Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
