Re: Heads Up: cirrus-ci is shutting down June 1st - Mailing list pgsql-hackers

From Jacob Champion
Subject Re: Heads Up: cirrus-ci is shutting down June 1st
Date
Msg-id CAOYmi+nEqAYKjh1r7HiKQ=LhFU5LMHw=XHuEkUr9We6b0judsg@mail.gmail.com
Whole thread
In response to Re: Heads Up: cirrus-ci is shutting down June 1st  (Andres Freund <andres@anarazel.de>)
Responses Re: Heads Up: cirrus-ci is shutting down June 1st
Re: Heads Up: cirrus-ci is shutting down June 1st
Re: Heads Up: cirrus-ci is shutting down June 1st
List pgsql-hackers
On Fri, Jun 12, 2026 at 2:54 PM Andres Freund <andres@anarazel.de> wrote:
> I did try creating an archive of an install, but that ends up with a good bit
> of additional complexity, because the installations aren't relocatable (there
> are header paths that are patched during install, apparently). And where the
> install should be depends on the runner type, larger runners don't have D:,
> but slower runners require using D:.  I think Bilal hacked further on my
> experiments around this, but I don't quite know where that stands. It's
> certainly not a trivial change.

Huh. (How does the current robocopy relocation work, then?)

I'll see if the `inherit` path changes in 0003 have made it
easier/harder to get the CPAN cache working.

> I'm pretty agnostic whether we want 0005, I just included that because it
> looks a bit nicer.

It does look a lot nicer.

> > I have questions about this. If we do this for all jobs then we can
> > end up having just too many uploaded files to look at. In this case,
> > unpacking .zip would be easier to access the logs of failed tasks.
>
> I was thinking we'd do this only for the first failure...

+1, I like the idea.

--Jacob



pgsql-hackers by date:

Previous
From: Jacob Champion
Date:
Subject: Re: [oauth] Increased CPU usage during device flow with libcurl 8.20.0
Next
From: Bharath Rupireddy
Date:
Subject: Re: Fix race condition in pg_get_publication_tables with concurrent DROP TABLE