Re: CI, macports, darwin version problems

Hi,

On 2024-07-03 09:39:06 +1200, Thomas Munro wrote:
> On Thu, Jun 27, 2024 at 6:32 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> > So I think we should request
> > ghcr.io/cirruslabs/macos-sonoma-base:latest.  Personal github accounts
> > will use macos-runner:sonoma instead, but at least it's the same OS
> > release.  Here's a new version like that, to see if cfbot likes it.
> 
> The first cfbot run of v3 was successful, but a couple of days later
> when retested it failed with the dreaded "Error:
> ShouldBeAtLeastOneLayer".  (It also failed on Windows, just because
> master was temporarily broken, unrelated to any of this.  Note also
> that the commit message created by cfbot now includes the patch
> version, making the test history easier to grok, thanks Jelte!)
> 
> https://cirrus-ci.com/github/postgresql-cfbot/postgresql/cf/5076
> 
> One difference that jumps out is that the successful v3 run has label
> worker:jc-m2-1 (Mac hosted by Joe), and the failure has
> worker:pgx-m2-1 (Mac hosted by Christophe P).  Is this a software
> version issue, ie need newer Tart to use that image, or could be a
> difficulty fetching the image?  CCing our Mac Mini pool attendants.
> 
> Temporary options include disabling pgx-m2-1 from the pool, or
> teaching .cirrus.task.yml to use Ventura for cfbot but Sonoma for
> anyone else's github account, but ideally we'd figure out why it's not
> working...

Yep, I think we'll have to do that, unless it has been fixed by now.


> This new information also invalidates my previous hypothesis, that the
> new "macos-runner:sonoma" image can't work on self-hosted Macs,
> because that was also on pgx-m2-1.

Besides the base-os-version issue, another theory is that the newer image is
just very large (141GB) and that we've seen some other issues related to
Christophe's internet connection not being the fastest.

WRT your patches:
- I think we ought to switch to the -runner image, otherwise we'll just
  continue to get that "upgraded" warning

- With a fingerprint_script specified, we need to add
  reupload_on_changes: true
  otherwise it'll not be updated.

- I think the fingerprint_script should use sw_vers, just as the script
  does. I see no reason to differ?

- We could just sw_vers -productVersion | sed 's/\..*//g' instead of the more
  complicated version you used, I doubt that they're going to go away from
  numerical major versions...

Greetings,

Andres Freund