search

actions / setup-python

Set up your GitHub Actions workflow with a specific version of Python
MIT License
1.59k stars 505 forks source link

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

Closed rouault closed 1 month ago

rouault commented 2 months ago

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

Runner images affected

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 commented 2 months ago

Hello @rouault, we will take a look.

mikhailkoliada commented 2 months ago

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

Josh00-Lu commented 2 months ago

@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 commented 2 months ago

@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 commented 2 months ago

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 https://github.com/OISF/suricata/pull/10948

rouault commented 1 month ago

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!