macos-14-arm64 with provisionner 2.0.361.1+33a726b54233caea13315dba3887b0e7c5a1d482 can no longer load Python extension

[rouault]

Description

The https://github.com/OSGeo/GDAL projects builds a Python extension and runs tests against it.

Last good build: https://github.com/OSGeo/gdal/actions/runs/8782968424/job/24098169250 , using Image Provisioner 2.0.321.1
First bad build: https://github.com/OSGeo/gdal/actions/runs/8783197992/job/24106391241, using Image provisionner 2.0.361.1+33a726b54233caea13315dba3887b0e7c5a1d482

With the new provisionner, tests fail with

45: ImportError while loading conftest '/Users/runner/work/gdal/gdal/build/autotest/conftest.py'.
43: conftest.py:9: in <module>
43:     from osgeo import gdal, ogr, osr
43: ../swig/python/osgeo/__init__.py:35: in <module>
43:     _gdal = swig_import_helper()
43: ../swig/python/osgeo/__init__.py:32: in swig_import_helper
43:     return importlib.import_module('_gdal')
43: E   ModuleNotFoundError: No module named '_gdal'

I've diffed the logs of the last good vs first bad build, and the only significant thing that changes is the version of the image provisionner. Our software has not changed in a significant way in between, and the version of Conda dependencies are exactly the same. And CI builds still work fine on other tests platforms (Linux, Windows)

Platforms affected

• Azure DevOps
• GitHub Actions - Standard Runners
• GitHub Actions - Larger Runners

Runner images affected

• Ubuntu 20.04
• Ubuntu 22.04
• macOS 11
• macOS 12
• macOS 13
• macOS 13 Arm64
• macOS 14
• macOS 14 Arm64
• Windows Server 2019
• Windows Server 2022

Image version and build link

##[group]Runner Image
Image: macos-14-arm64
Version: 20240415.6
Image provisionner 2.0.361.1+33a726b54233caea13315dba3887b0e7c5a1d482

Is it regression?

yes, runner Image Provisioner 2.0.321.1 was fine

Expected behavior

Python extension should load

Actual behavior

It doesn't load

Repro steps

Trigger a build of the GDAL continusous integrations

[Alexey-Ayupov]

Hello @rouault, we will take a look.

[mikhailkoliada]

@rouault we do not manage python environments directly on the image, so it looks like pythonish problems transferring to setup-python

[Josh00-Lu]

@rouault we do not manage python environments directly on the image, so it looks like pythonish problems transferring to setup-python

Well... This may inference a lot of python workflows on Github. My workflows for MacOS are all broken with:

Run actions/setup-python@v2
Version 3.8 was not found in the local cache
Error: Version 3.8 with arch arm[6](https://github.com/vwxyzjn/cleanrl/actions/runs/8800849834/job/24152897738#step:3:7)4 not found
The list of all available versions can be found here: https://raw.githubusercontent.com/actions/python-versions/main/versions-manifest.json

[rouault]

@mikhailkoliada I'm a bit skeptical that my issue is related with action/setup-python because the workflow that started to fail with the new image provisionner does not use action/setup-python. See https://github.com/OSGeo/gdal/blob/master/.github/workflows/macos.yml

[catenacyber]

Seeing a similar problem in suricata :
https://github.com/OISF/suricata/actions/runs/8791375375/job/24131950813?pr=10930#step:6:13

we need C libyaml, and also pyyaml for our test framework...

Tried a lot of things but did not get any of the proposed workarounds to work cf OISF/suricata#10948

• brew install pyyaml, is then not found by our test framework
• --break-system-packages looks like breaking libyaml, same for virtual env...
• pipx cannot install pyyaml as it is a library

[rouault]

I'm closing this ticket as invalid. It turns out the issue was entirely on GDAL side (a version number bump which revealed an underlying issue that had been unnoticed previously), and had nothing with the bump of the action provisionner. Apologies for the distraction!