On Mon, Nov 21, 2022 at 02:45:42PM -0800, Andres Freund wrote: > On 2022-11-13 17:53:04 -0600, Justin Pryzby wrote: > > > > From: Justin Pryzby <pryz...@telsasoft.com> > > > > Date: Tue, 26 Jul 2022 20:30:02 -0500 > > > > Subject: [PATCH 6/8] cirrus/ccache: add explicit cache keys.. > > > > > > > > Since otherwise, building with ci-os-only will probably fail to use the > > > > normal cache, since the cache key is computed using both the task name > > > > and its *index* in the list of caches (internal/executor/cache.go:184). > > > > > > Seems like this would potentially better addressed by reporting a bug to > > > the > > > cirrus folks? > > > > You said that before, but I don't think so - since they wrote code to do > > that, it's odd to file a bug that says that the behavior is wrong. I am > > curious why, but it seems delibrate. > > > > https://www.postgresql.org/message-id/20220828171029.GO2342%40telsasoft.com > > I suspect this is just about dealing with unnamed tasks and could be > handled by just mixing in CI_NODE_INDEX if the task name isn't set.
I suppose it was their way of dealing with this: |Cache artifacts are shared between tasks, so two caches with the same |name on e.g. Linux containers and macOS VMs will share the same set of |files. This may introduce binary incompatibility between caches. To |avoid that, add echo $CIRRUS_OS into fingerprint_script or use |$CIRRUS_OS in fingerprint_key, which will distinguish caches based on |OS. To make caches work automatically, without having to know to name them differently. -- Justin
