Hi,
On 2024-11-27 16:33:02 +0300, Nazir Bilal Yavuz wrote:
> I think this is a nice solution and it worked successfully [1]. Now,
> REL_[17 | 16]_* and master branches use the same cache which is
> different from the REL_15_STABLE branch's cache.
>
> In case you want to continue with this, the pa
Hi,
On Fri, 22 Nov 2024 at 20:28, Andres Freund wrote:
> The right approach probably is to include the list of packages in the key. A
> bit annoying to change, because we'd need to move the list of packages to an
> environment variable or file, but doable. I think something like
>
> env:
> MACO
Hi,
On 2024-11-21 14:24:26 +1300, Thomas Munro wrote:
> Oh, and yeah, we should include the branch name in the cache key.
> Something like the attached.
I think that'd be too granular - we'd end up with lots of copies of
effectively the same cache, but which won't exactly the same due to timestam
Oh, and yeah, we should include the branch name in the cache key.
Something like the attached. For some reason CI is not allowing me to
see the output from macOS right now (?!) so I couldn't see what
"Populate macports cache" printed out[1], but I think this should be
right... will try again tomor
On Sun, Nov 17, 2024 at 2:17 PM Andres Freund wrote:
> Whenever the cache was built with 15, 16 would fail, because gmake was
> installed but not meson. And vice versa. It gets worse, see further down.
Argh...
> The easiest fix I can see is to simply loop over the to-be-installed installed
> pac
Hi,
I noticed that CI tasks on the postgres' github repo fail for some branches on
macos [1].
Initially I thought the problem was related to some outdated cache of the
macports installation. And indeed clearing that out does fix the issue - but
only temporarily and fixing one branch would cause s
