From: Anton Mikanovich <amikan@ilbers.de>
To: Adriaan Schmidt <adriaan.schmidt@siemens.com>,
isar-users@googlegroups.com
Subject: Re: [PATCH v2 0/7] Sstate maintenance script
Date: Wed, 18 May 2022 14:02:09 +0300 [thread overview]
Message-ID: <382ebe88-4215-3fda-feca-68832d1f52dd@ilbers.de> (raw)
In-Reply-To: <20220509101604.3249558-1-adriaan.schmidt@siemens.com>
09.05.2022 13:15, Adriaan Schmidt wrote:
> We have been running CI with shared sstate caches for some months now, in
> several downstream projects. This is the cache maintenance script that has
> evolved during that time. Detailed documentation is in the script itself.
> Main features:
> - upload cache artifacts to shared caches on filesystem, http, or s3
> - clean old artifacts from shared caches
> - analyze in detail why cache misses happen (what has changed in the signatures)
> - check the sstate signatures for absolute paths pointing to the build host
>
> The last two are especially interesting, and have already yielded some
> improvements to the cacheability of Isar, some already merged, and some
> more in "[PATCH 0/7] Further improve cachability of ISAR".
>
> p1 handles another absolute path in a variable (LAYERDIR_isar).
> p2..3 are minor patches to bitbake (both already upstream) that greatly
> improve accuracy and performance of the sstate analysis.
> p4 refactors handling of the apt_* tasks. This was motivated by the sstate
> analysis, but I think it also makes the code cleaner.
> p5..6 add the sstate maintenance script (2 authors, hence 2 patches).
> p7 includes a signature check into the sstate test case. This requires the
> changes from "[PATCH 0/7] Further improve cachability of ISAR" for the
> test to pass.
>
> One issue: testing!
> This is not easy, because it involves infrastructure, and artificial tests
> that provide decent coverage would be quite complex to design.
>
> If we declare that we sufficiently trust the sstate code, we could add a
> shared/persistent cache to the Isar CI infrastructure. This would further test
> the sstate feature and all steps involved in maintaining such a setup.
> In addition, it would significantly speed up CI builds.
>
> changes since v1:
> - generally improved script
> - analysis and cachability improvements in bitbake, dpkg-base, and meta-isar
> - added "sstate linting" to the testsuite
>
> Adriaan Schmidt (6):
> meta-isar: improve cachability
> bitbake-diffsigs: make finding of changed signatures more robust
> bitbake-diffsigs: break on first dependent task difference
> dpkg-base: refactor dependencies of apt_* tasks
> scripts: add isar-sstate
> testsuite: add cachability analysis to sstate test
>
> Felix Moessbauer (1):
> isar-sstate: add tool to check for caching issues
>
> bitbake/lib/bb/siggen.py | 11 +-
> meta-isar/conf/layer.conf | 1 +
> meta/classes/dpkg-base.bbclass | 14 +-
> meta/classes/dpkg.bbclass | 2 +-
> scripts/isar-sstate | 863 +++++++++++++++++++++++++++++++++
> testsuite/cibase.py | 8 +-
> 6 files changed, 884 insertions(+), 15 deletions(-)
> create mode 100755 scripts/isar-sstate
>
Applied to next, thanks.
prev parent reply other threads:[~2022-05-18 11:02 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-09 10:15 Adriaan Schmidt
2022-05-09 10:15 ` [PATCH v2 1/7] meta-isar: improve cachability Adriaan Schmidt
2022-05-09 10:15 ` [PATCH v2 2/7] bitbake-diffsigs: make finding of changed signatures more robust Adriaan Schmidt
2022-05-09 10:16 ` [PATCH v2 3/7] bitbake-diffsigs: break on first dependent task difference Adriaan Schmidt
2022-05-09 10:16 ` [PATCH v2 4/7] dpkg-base: refactor dependencies of apt_* tasks Adriaan Schmidt
2022-05-09 10:16 ` [PATCH v2 5/7] scripts: add isar-sstate Adriaan Schmidt
2022-05-09 10:16 ` [PATCH v2 6/7] isar-sstate: add tool to check for caching issues Adriaan Schmidt
2022-05-09 10:16 ` [PATCH v2 7/7] testsuite: add cachability analysis to sstate test Adriaan Schmidt
2022-05-18 11:02 ` Anton Mikanovich [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=382ebe88-4215-3fda-feca-68832d1f52dd@ilbers.de \
--to=amikan@ilbers.de \
--cc=adriaan.schmidt@siemens.com \
--cc=isar-users@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox