Github-hosted runners for OSX no longer carry a bundled conda installation

[jaimergp]

See https://github.com/conda/conda-standalone/actions/runs/8796238715/job/24143815312?pr=67.

macos-latest runners will now default to macOS 14, which means they run on ARM64 Apple Silicon, not Intel! This breaks the assumption of macos-latest == x86_64. Just a heads up!

We should document this.

The current recommendation is to pin directly to macos-13 to ensure you get an Intel runner. Make sure you are using setup-miniconda@v3.

[mattwthompson]

I'm a bit lost here

macos-latest runners will now default to macOS 14

Is this change live? The blog says it'll happen at some point in the next 12 weeks from April 1, but no updates there. This page indicates it's already happened to macos-latest and to get x86 we need to call out macos-13?

[jaimergp]

Yes, I'm observing it in some repos already. See the linked CI run above.

[mattwthompson]

Must have happened overnight? Wonder if there'll be an announcement today then

[mattwthompson]

I'm not seeing this change live: https://github.com/mattwthompson/gha-sandbox/actions/runs/8803326872/job/24161162575#step:3:5

[jaimergp]

Yep, you got macos-12 there (check first step). This will take 12 weeks, and we are currently starting the 4th-ish. It might hit you latee, but it will 😁

[mattwthompson]

Thanks for that - I totally forgot to see what that label actually pulls down

[briantoby]

Looking forward, is it likely there will be a time when only MacOS/ARM-based runners are available? If so, should there be a way to specify that one wants to use a x86_64 miniconda even if running on ARM? I can imagine that I will want to build for x86_64 for several more years. It seems to me that tying the CPU architecture to a specific runner is going to be a problem down the road.

[jaimergp]

There's an architecture setting, and also installer-url if everything fails, so I think it should be fine.

[valeriupredoi]

Hi @jaimergp - good catch! And we've literally just noticed this by upgrading to v4, see ESMValGroup/ESMValCore#2411 (comment) - the problem is that in the future there will be fewer and fewer nodes that will run v3 (GHA already toss warnings that one should update the action to latest version, since such and such node are the only ones able to execute the older version). BTW using macos-latest and setup-miniconda@v3 works in the sense that the Setup job installs the arm64 container but the deps are the generic osx-64 builds (see my comment with links to GHA runs, in our PR). Cheers muchly for the good work you folks do here BTW 🍺

[valeriupredoi]

I found out that forcing the Intel architecture as:

  osx:
    runs-on: "macos-latest"
    strategy:
      matrix:
        python-version: ["3.9", "3.10", "3.11"]
        architecture: ["x64"]
      fail-fast: false
    name: OSX Python ${{ matrix.python-version }}
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: conda-incubator/setup-miniconda@v3
        with:
          architecture: ${{ matrix.architecture }}
          activate-environment: esmvalcore
          environment-file: environment.yml
          python-version: ${{ matrix.python-version }}
          miniforge-version: "latest"
          miniforge-variant: Mambaforge
          use-mamba: true

works biutifully even with the ARM64 processor and v4, well at least for now, before they diverge completely 🥳