From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 7016230395466219520 X-Received: by 2002:a1c:ac03:: with SMTP id v3mr6282198wme.127.1635444419928; Thu, 28 Oct 2021 11:06:59 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a5d:6b08:: with SMTP id v8ls4725875wrw.3.gmail; Thu, 28 Oct 2021 11:06:59 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyXYuYi5aQzf4FwMDVoMXnWT/IK2nxZvdMKN7auyS2kzJPpCVjN5ICcoxw//+gvMXZ9UvgK X-Received: by 2002:adf:e984:: with SMTP id h4mr4125510wrm.149.1635444418992; Thu, 28 Oct 2021 11:06:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635444418; cv=none; d=google.com; s=arc-20160816; b=xFkHgAeiHrtoP//vzyTbCOD8p35eYQ+XBWa3JdpED1fTdygSD1IfdZfQ56D2U5Ywrb VgegKw/RXBRhZnB45QH9qB4S3+NKLeNyUFK16uI98g77NJZxXdbSq04wzmOg/NWH7mYk 1ajQICBbxs/fP4vF7IN5DHhK7GrPuKeAE52mb9ivLBdBPH52RvYNgW5hEYtw0DCutPbe 4zRVi+BJKWNxQHMB1rwr0ZPp6++svms4bXRG/FKRGPfJsrim/4apOWhVxn6LFsisPIZK jd69/C9byPdgch2VfOkqo34lWF4m6tSvrxLyJqHJAvEuuUWV12+yCO/kPxyRqs7wQ28l C18g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date; bh=dsmkm3Bb4lrzbFQ7B/IWFj7Lh1GEh+zcjC0v4eYkSyY=; b=hnLIQs+H/zy65JpoMWUO3tkrZixriAn5BE5r204TG1DGYSgCIBD1U2H37Y2Zx1o1KQ 5edPzHrYmP75kt3q/q0sPKVq2h2hiWLcEXTJepGEviVG7tyuWjUJq+pBqsU8pSSdVj/Q LjyESgNZa301D9zpoYiZ1acxi9kavux/gmGSMxIwZIjilSh3+wRiKP5rMfDKR45MIKW7 IJf6+MINZDVzttSWp/S1Lll6eb6Q2HN1reL6DXZO1ISe3e3pRRZyBtezO/w2Vp/WsChL /vKn7X2PHTIZ/zFvKpSL53D+9lsMxQNoksqyEXXVCQXPQ7A4h3lH60K24Stw0FsU3FGF ruew== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.2 as permitted sender) smtp.mailfrom=henning.schild@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Return-Path: Received: from thoth.sbs.de (thoth.sbs.de. [192.35.17.2]) by gmr-mx.google.com with ESMTPS id l9si516710wmh.3.2021.10.28.11.06.58 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Oct 2021 11:06:58 -0700 (PDT) Received-SPF: pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.2 as permitted sender) client-ip=192.35.17.2; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.2 as permitted sender) smtp.mailfrom=henning.schild@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by thoth.sbs.de (8.15.2/8.15.2) with ESMTPS id 19SI6wb2013967 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 28 Oct 2021 20:06:58 +0200 Received: from md1za8fc.ad001.siemens.net ([167.87.32.106]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTP id 19SI6w25020944; Thu, 28 Oct 2021 20:06:58 +0200 Date: Thu, 28 Oct 2021 20:06:57 +0200 From: Henning Schild To: Anton Mikanovich Cc: Adriaan Schmidt , isar-users@googlegroups.com Subject: Re: [PATCH v4 00/10] Add sstate-cache Message-ID: <20211028200657.12306539@md1za8fc.ad001.siemens.net> In-Reply-To: <11f725c1-20b5-5a57-7ec1-4dc29901ec21@ilbers.de> References: <20211026122811.2654125-1-adriaan.schmidt@siemens.com> <11f725c1-20b5-5a57-7ec1-4dc29901ec21@ilbers.de> X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TUID: 2ukCHUyMMaL8 Am Thu, 28 Oct 2021 18:23:01 +0300 schrieb Anton Mikanovich : > 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