On Tue, 2023-10-17 at 17:33 +0200, Alexander Kanavin wrote: > Thanks for working on this! I finally got to playing with CDN mirror a > bit, and it seems to basically work ok, so next I'm going to write AB > tests that check that it remains useful. Specifically: > > 1. What should the test be? > > I tried 'bitbake -S printdiff core-image-sato' on a blank build > directory, and the result against current master is: > > =========== > Checking sstate mirror object availability: 100% > > ##################################################################################################################################################| > Time: 0:05:35 > The differences between the current build and any cached tasks start > at the following tasks: > /srv/work/alex/poky/meta/recipes-sato/images/core-image-sato.bb:do_deploy_source_date_epoch > /srv/work/alex/poky/meta/recipes-core/base-files/base-files_3.0.14.bb:do_install > =========== > > I think this is pretty good! The two missing objects depend on the > current date, and so should go to the exception list in the test, and > otherwise there is a 100% match rate. The bitbake targets could be > 'world core-image-sato-sdk', and target machines could be qemux86_64 > and qemuarm64.
That match does look good. As you say, the revision of the metadata will change base-files so that is expected. I'm torn on the targets to test as sato-sdk is a large image and world is a lot of work. I'd be tempted to test sato, weston and full-cmdline? World is a good test I guess and if from sstate, shouldn't have that much of an issue. It does also prove things are working. > Just to be sure that mismatches elsewhere will be reported as CDN > misses, adding my shadow 4.14 update and re-running the command shows: > ============ > The differences between the current build and any cached tasks start > at the following tasks: > /srv/work/alex/poky/meta/recipes-gnome/hicolor-icon-theme/hicolor-icon-theme_0.17.bb:do_package > /srv/work/alex/poky/meta/recipes-sato/pulseaudio-sato/pulseaudio-client-conf-sato_1.bb:do_package > /srv/work/alex/poky/meta/recipes-core/initscripts/initscripts_1.0.bb:do_package > /srv/work/alex/poky/meta/recipes-core/update-rc.d/update-rc.d_0.8.bb:do_package > /srv/work/alex/poky/meta/recipes-multimedia/alsa/alsa-ucm-conf_1.2.10.bb:do_package > /srv/work/alex/poky/meta/recipes-kernel/wireless-regdb/wireless-regdb_2023.09.01.bb:do_package > /srv/work/alex/poky/meta/recipes-sato/packagegroups/packagegroup-core-x11-sato.bb:do_package > /srv/work/alex/poky/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_6.5.bb:do_package > /srv/work/alex/poky/meta/recipes-core/packagegroups/packagegroup-core-ssh-dropbear.bb:do_package > /srv/work/alex/poky/meta/recipes-graphics/packagegroups/packagegroup-core-x11.bb:do_package > /srv/work/alex/poky/meta/recipes-sato/shutdown-desktop/shutdown-desktop.bb:do_package > virtual:native:/srv/work/alex/poky/meta/recipes-support/libbsd/libbsd_0.11.7.bb:do_prepare_recipe_sysroot > /srv/work/alex/poky/meta/recipes-support/ca-certificates/ca-certificates_20211016.bb:do_package > /srv/work/alex/poky/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb:do_package > virtual:native:/srv/work/alex/poky/meta/recipes-extended/shadow/shadow_4.14.0.bb:do_recipe_qa > ... (a few more missing do_package objects) > =========== > > 2. When to run the test, and against which commit in poky? > > RP suggested that the test could run in an antiphase with the nightly > a-quick (i.e. 12 hours after). We can do that for a start, but I'm > (perhaps prematurely) worrying that this will be unstable: either > because the objects from the nightly haven't yet propagated to CDN, or > because master has meanwhile (e.g. in the 12 hours that have passed) > gained new commits without corresponding cache objects. Are those real > concerns? > > Thoughts? You're right, we need to run the test against a commit we know has been built on the autobuilder. If we run with a newer commit we could easily see mismatch since it won't have been built yet. I'm less worried about CDN propagation, that should happen quickly and if something isn't present, it might just be slow to obtain/lookup as it ripples through the system. Either we start logging what we've built so we get the last known revisions, or we run the test as part of a-quick/a-full at the end of the build? I don't really want to extend the build but I'm not sure we may have much choice. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#61387): https://lists.yoctoproject.org/g/yocto/message/61387 Mute This Topic: https://lists.yoctoproject.org/mt/101525879/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/leave/6691583/21656/737036229/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
