Re: [PATCH v4 00/10] Add sstate-cache

[Henning Schild <henning.schild@siemens.com>]

Am Thu, 28 Oct 2021 18:23:01 +0300
schrieb Anton Mikanovich <amikan@ilbers.de>:

> 26.10.2021 15:28, Adriaan Schmidt wrote:
> > This series adds the sstate-cache feature from OE to Isar. The
> > cache holds the results of bootstrapping, rootfs generation
> > (buildchroot, image rootfs), and deb package generation.
> >
> > To use the cache, the only configuration neccessary is setting
> > SSTATE_DIR. The contents of that directory need to be preserved
> > across bitbake invocations.
> >
> > One known weakness is that the package lists of cached rootfs's can
> > run out of sync with upstream ("apt-get update" only happens at
> > bootstrap time). But this also happens with an "old" local build
> > dir, and is something that may be addressed elsewhere. For now, the
> > recommendation is to frequently clear the cache (in one of our
> > projects we run a nightly "clear&populate cache" CI job).
> >
> > Patches 1..5 fix (unrelated) issues that would otherwise block
> > sstate caching, patch 6 copies files from OE, and patches 7..10 add
> > caching to Isar.  
> 
> Suggest adding `[PATCH] CI: Add sstate-cache testcase` as a test case 
> for sstate-cache usage.

I think that was pure "show" to see things become faster. Given people
configure their CI runners to use sstate it will be tested a lot
anyways, including functional tests with qemu later on.

If you want to add it for the full path (which might be running nightly
without cache, but populate it for the next day), it should be put into
the pipeline before the functional tests.

We have cron jobs on our sstate enabled runners that clear+build every
night, so the next day we have fresh chroots with up to date apt
databases and builds that only take minutes. In fact not cron jobs, but
scheduled ci jobs. So the runners stay "stupid CPU+storage", easy to
throw away, easy to deploy and grow.

Henning