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 <pryzbyj@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