Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

macos-latest runners do not always have the same OS version #8642

Closed
2 of 10 tasks
paulmueller opened this issue Oct 24, 2023 · 14 comments
Closed
2 of 10 tasks

macos-latest runners do not always have the same OS version #8642

paulmueller opened this issue Oct 24, 2023 · 14 comments

Comments

@paulmueller
Copy link

Description

The readme for the macOS 12 runner says that the OS version is 12.7.

However, I am seeing runners with 12.6.8 and 12.6.9 when I set the os to "macos-latest".

Is this behavior intended?

Background: My problem is apparently that my tests fail with the macOS 12.6.9 image but succeed with the macOS 12.6.8 and 12.7 images.

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
  • Windows Server 2019
  • Windows Server 2022

Image version and build link

macOS 12.7: https://github.com/DCOR-dev/ckanext-dcor_schemas/actions/runs/6619079303/job/17978854847
macOS 12.6.9: https://github.com/DCOR-dev/ckanext-dcor_schemas/actions/runs/6623038566/job/17989672981

Is it regression?

no

Expected behavior

If I specify macos-latest, I expect to always get the same runner image with currently macOS 12.7

Actual behavior

Sometimes macOS 12.6.8 or 12.6.9 images are used.

Repro steps

Just use the macos-latest runner.

@ilia-shipitsin
Copy link
Contributor

Hello, @paulmueller . it is not regarding images, I'd say it is how VM is chosen for your build.
I'll ask colleagues

@jan-janssen
Copy link

jan-janssen commented Oct 31, 2023

The issue is in the images:

Current runner version: '2.311.0'
Operating System
  macOS
  12.7
  21G816
Runner Image
  Image: macos-12
  Version: 20230921.4
  Included Software: https://github.com/actions/runner-images/blob/macOS-12/20230921.4/images/macos/macos-12-Readme.md
  Image Release: https://github.com/actions/runner-images/releases/tag/macOS-12%2F20230921.4

vs.

Current runner version: '2.311.0'
Operating System
  macOS
  12.6.9
  21G726
Runner Image
  Image: macos-12
  Version: 20231017.6
  Included Software: https://github.com/actions/runner-images/blob/macOS-12/20231017.6/images/macos/macos-12-Readme.md
  Image Release: https://github.com/actions/runner-images/releases/tag/macOS-12%2F20231017.6

The version number of the 12.6.9 image 20231017.6 is higher than the version number of the 12.7 image 20230921.4 so the runner chooses the image with 12.6.9 rather than 12.7. Is there anyway to enforce the image version ?

The link for the image seems to be broken as well: https://github.com/actions/runner-images/releases/tag/macOS-12%2F20231017.6 vs. https://github.com/actions/runner-images/releases/tag/macOS-12%2F20230921.4 . So it seems to me the image should be removed.

@Release-Candidate
Copy link

Another problem of these images is that different Mac OS 12 images use either Python 2 or Python 3 when using shell: python in the workflow YAML, depending on the exact runner: #8842

mattbrictson added a commit to capistrano/sshkit that referenced this issue Nov 22, 2023
We rely on VirtualBox running in a GitHub Actions macOS runner image for
our functional (Cucumber) tests.

There was a long-standing issue in the GitHub Actions runner image that
caused VirtualBox to fail, breaking our CI builds. This issue has
recently been fixed with a new version of the macOS runner image.

actions/runner-images#8730

However, another GitHub Actions bug means that our CI builds are not
getting the newest macOS runner image. So our builds continue to fail.

actions/runner-images#8642

Until this is resolved, I am disabling functional tests in CI so that
contributors aren't blocked by failing builds that they can't do
anything to fix.
mattbrictson added a commit to capistrano/sshkit that referenced this issue Nov 22, 2023
We rely on VirtualBox running in a GitHub Actions macOS runner image for
our functional (Cucumber) tests.

There was a long-standing issue in the GitHub Actions runner image that
caused VirtualBox to fail, breaking our CI builds. This issue has
recently been fixed with a new version of the macOS runner image.

actions/runner-images#8730

However, another GitHub Actions bug means that our CI builds are not
getting the newest macOS runner image. So our builds continue to fail.

actions/runner-images#8642

Until this is resolved, I am disabling functional tests in CI so that
contributors aren't blocked by failing builds that they can't do
anything to fix.
@akhilamoyila9
Copy link

It appears that there is inconsistency in the macOS versions used by the GitHub Actions runners labeled as macos-12. In some cases, the runner reports macOS version 12.6.9, while in other instances, it reports macOS version 12.7.1.

macOS 12.6.9: https://github.com/magma/magma/actions/runs/6963469881/job/18952865170
macOS 12.7.1: https://github.com/magma/magma/actions/runs/6956320863/job/18926933323
This variability is unexpected as macos-12 is generally expected to provide the most recent macOS version.

@ilia-shipitsin
Copy link
Contributor

ilia-shipitsin commented Nov 23, 2023

sorry for delayed reply.

it is not only version split 12.7.1 / 12.6.9, it is rather underlying hardware difference.
macos 12 build are routed to 2 kind of virtual machines . It is not something we can address on image generation level, unfortunately.

some day all builds hopefully be routed to single hardware (I was told that it should happen in 2024).

also, some statement from my colleagues (regarding difference in virtualization on those hardware)

We invested in upgraded hardware to support macOS 13 and are retiring older hardware, both of these changes impact macOS 12. The older generation Mac hardware was more efficient at nested virtualization. We recommend using larger linux runners for workflows that require nested virtualization. More information can be found here.

@tapasmishra
Copy link

it is not only version split 12.7.1 / 12.6.9, it is rather underlying hardware difference.
macos 12 build are routed to 2 kind of virtual machines . It is not something we can address on image generation level, unfortunately.

@ilia-shipitsin As per my understanding, the runners always use the latest image version, and that is one of the reasons why the option to specify/use a particular image version is restricted in the workflows. If my understanding is correct, then no matter which hardware the job is getting routed to, it should use the latest OS image version. I am a little confused when you mention two different types of hardware using two different versions of the same OS. It sounds illogical. Can you help us identify the correct repository to raise an issue if this issue is not related to runner images?

@ilia-shipitsin
Copy link
Contributor

your understanding absolutely makes sense.
I suggest to try https://support.github.com , but I heard from colleagues that for some period of time we'll be running macos 12 like that, unfortunately

marcofavoritobi added a commit to bancaditalia/black-it that referenced this issue Dec 7, 2023
This change was needed because of a nondeterminism in how the macos-12 (=macos-latest at the time of writing) runner image was instantiated by GitHub Actions.
In particular, for runner version 2.311.0, the operating system was nondeterministically chosen between 12.6.9 and 12.7.1, as it can be seen in these two GH runs:
- https://github.com/bancaditalia/black-it/actions/runs/7128997647/job/19412070642
- https://github.com/bancaditalia/black-it/actions/runs/7128997647/job/19412070868

This is a known issue in the community: see actions/runner-images#8642

Furthermore, at the time of writing, it is suspected that Python code that uses pytables is not stable over macos at version 12.7.1 (but this problem does not occur on v12.6.9!), as witnessed by this issue: PyTables/PyTables#1093

What happened in our CI workflow is that tests resulted in a flaky outcome, but not because of our tests, but due to the nondeterminism in how the macos runner was instantiated by GitHub Actions.

This was not our unique attempt. In fact, we first tried to improve the preliminary configuration steps for the testing environment, as follows:
- if: matrix.os == 'macos-latest'
      name: Install dependencies (macos-latest)
      run: |
        # for some reason this seems to be a necessary step for MacOS images, but not for Ubuntu and Windows
        brew install hdf5
        brew install c-blosc
        # https://stackoverflow.com/questions/73029883/could-not-find-hdf5-installation-for-pytables-on-m1-mac
        echo "HDF5_DIR=/usr/local/" >> $GITHUB_ENV
        echo "BLOSC_DIR=/usr/local/" >> $GITHUB_ENV

This attempt consisted in installing HDF5 and C-blosc explicitly in the preliminary steps on CI for MacOS images. By the way, this step was part of the installation instructions of PyTables v3.9.2: https://github.com/PyTables/PyTables/blob/v3.9.2/README.rst#installation , although it seems this step is not actually needed.
Moreover, as explained here: https://stackoverflow.com/questions/73029883/could-not-find-hdf5-installation-for-pytables-on-m1-mac, sometimes must be explicitly set the environment path variables where HDF5 ahd C-blosc are installed
For some reason this is not needed on Ubuntu and Windows runners.

However, despite our efforts in this direction, the issue with pytables persisted. From the logs of the CI: (https://github.com/bancaditalia/black-it/actions/runs/7121188681/job/19389914846?pr=78#step:5:62)

```
Fatal Python error: Illegal instruction

Current thread 0x000000011783c600 (most recent call first):
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/tables/node.py", line 246 in __init__
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/tables/leaf.py", line 264 in __init__
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/tables/carray.py", line 200 in __init__
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/tables/earray.py", line 143 in __init__
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/tables/file.py", line 1345 in create_earray
  File "/Users/runner/work/black-it/black-it/black_it/utils/json_pandas_checkpointing.py", line 211 in save_calibrator_state
  File "/Users/runner/work/black-it/black-it/tests/test_utils/test_pandas_json_checkpointing.py", line 58 in test_save_and_load_calibrator_state
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/_pytest/python.py", line 194 in pytest_pyfunc_call
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/pluggy/_callers.py", line 77 in _multicall
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/pluggy/_manager.py", line 115 in _hookexec
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/pluggy/_hooks.py", line 493 in __call__
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/_pytest/python.py", line 1792 in runtest
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/_pytest/runner.py", line 169 in pytest_runtest_call
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/pluggy/_callers.py", line 77 in _multicall
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/pluggy/_manager.py", line 115 in _hookexec
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/pluggy/_hooks.py", line 493 in __call__
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/_pytest/runner.py", line 262 in <lambda>
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/_pytest/runner.py", line 341 in from_call
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/_pytest/runner.py", line 261 in call_runtest_hook
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/_pytest/runner.py", line 222 in call_and_report
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/_pytest/runner.py", line 133 in runtestprotocol
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/_pytest/runner.py", line 114 in pytest_runtest_protocol
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/pluggy/_callers.py", line 77 in _multicall
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/pluggy/_manager.py", line 115 in _hookexec
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/pluggy/_hooks.py", line 493 in __call__
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/_pytest/main.py", line 350 in pytest_runtestloop
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/pluggy/_callers.py", line 77 in _multicall
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/pluggy/_manager.py", line 115 in _hookexec
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/pluggy/_hooks.py", line 493 in __call__
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/_pytest/main.py", line 325 in _main
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/_pytest/main.py", line 271 in wrap_session
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/_pytest/main.py", line 318 in pytest_cmdline_main
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/pluggy/_callers.py", line 77 in _multicall
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/pluggy/_manager.py", line 115 in _hookexec
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/pluggy/_hooks.py", line 493 in __call__
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/_pytest/config/__init__.py", line 169 in main
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/_pytest/config/__init__.py", line 192 in console_main
  File "/Users/runner/work/black-it/black-it/.tox/py310/bin/pytest", line 8 in <module>
```

Therefore, the current workaround we adopted was to downgrade the version of the macos runner to the previous version, 11.
marcofavoritobi added a commit to bancaditalia/black-it that referenced this issue Dec 7, 2023
This change was needed because of a nondeterminism in how the macos-12 (=macos-latest at the time of writing) runner image was instantiated by GitHub Actions.
In particular, for runner version 2.311.0, the operating system was nondeterministically chosen between 12.6.9 and 12.7.1, as it can be seen in these two GH runs:
- https://github.com/bancaditalia/black-it/actions/runs/7128997647/job/19412070642
- https://github.com/bancaditalia/black-it/actions/runs/7128997647/job/19412070868

This is a known issue in the community: see actions/runner-images#8642

Furthermore, at the time of writing, it is suspected that Python code that uses pytables is not stable over macos at version 12.7.1 (but this problem does not occur on v12.6.9!), as witnessed by this issue: PyTables/PyTables#1093

What happened in our CI workflow is that tests resulted in a flaky outcome, but not because of our tests, but due to the nondeterminism in how the macos runner was instantiated by GitHub Actions.

This was not our unique attempt. In fact, we first tried to improve the preliminary configuration steps for the testing environment, as follows:
- if: matrix.os == 'macos-latest'
      name: Install dependencies (macos-latest)
      run: |
        # for some reason this seems to be a necessary step for MacOS images, but not for Ubuntu and Windows
        brew install hdf5
        brew install c-blosc
        # https://stackoverflow.com/questions/73029883/could-not-find-hdf5-installation-for-pytables-on-m1-mac
        echo "HDF5_DIR=/usr/local/" >> $GITHUB_ENV
        echo "BLOSC_DIR=/usr/local/" >> $GITHUB_ENV

This attempt consisted in installing HDF5 and C-blosc explicitly in the preliminary steps on CI for MacOS images. By the way, this step was part of the installation instructions of PyTables v3.9.2: https://github.com/PyTables/PyTables/blob/v3.9.2/README.rst#installation , although it seems this step is not actually needed.
Moreover, as explained here: https://stackoverflow.com/questions/73029883/could-not-find-hdf5-installation-for-pytables-on-m1-mac, sometimes must be explicitly set the environment path variables where HDF5 ahd C-blosc are installed
For some reason this is not needed on Ubuntu and Windows runners.

However, despite our efforts in this direction, the issue with pytables persisted. From the logs of the CI: (https://github.com/bancaditalia/black-it/actions/runs/7121188681/job/19389914846?pr=78#step:5:62)

```
Fatal Python error: Illegal instruction

Current thread 0x000000011783c600 (most recent call first):
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/tables/node.py", line 246 in __init__
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/tables/leaf.py", line 264 in __init__
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/tables/carray.py", line 200 in __init__
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/tables/earray.py", line 143 in __init__
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/tables/file.py", line 1345 in create_earray
  File "/Users/runner/work/black-it/black-it/black_it/utils/json_pandas_checkpointing.py", line 211 in save_calibrator_state
  File "/Users/runner/work/black-it/black-it/tests/test_utils/test_pandas_json_checkpointing.py", line 58 in test_save_and_load_calibrator_state
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/_pytest/python.py", line 194 in pytest_pyfunc_call
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/pluggy/_callers.py", line 77 in _multicall
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/pluggy/_manager.py", line 115 in _hookexec
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/pluggy/_hooks.py", line 493 in __call__
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/_pytest/python.py", line 1792 in runtest
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/_pytest/runner.py", line 169 in pytest_runtest_call
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/pluggy/_callers.py", line 77 in _multicall
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/pluggy/_manager.py", line 115 in _hookexec
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/pluggy/_hooks.py", line 493 in __call__
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/_pytest/runner.py", line 262 in <lambda>
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/_pytest/runner.py", line 341 in from_call
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/_pytest/runner.py", line 261 in call_runtest_hook
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/_pytest/runner.py", line 222 in call_and_report
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/_pytest/runner.py", line 133 in runtestprotocol
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/_pytest/runner.py", line 114 in pytest_runtest_protocol
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/pluggy/_callers.py", line 77 in _multicall
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/pluggy/_manager.py", line 115 in _hookexec
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/pluggy/_hooks.py", line 493 in __call__
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/_pytest/main.py", line 350 in pytest_runtestloop
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/pluggy/_callers.py", line 77 in _multicall
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/pluggy/_manager.py", line 115 in _hookexec
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/pluggy/_hooks.py", line 493 in __call__
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/_pytest/main.py", line 325 in _main
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/_pytest/main.py", line 271 in wrap_session
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/_pytest/main.py", line 318 in pytest_cmdline_main
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/pluggy/_callers.py", line 77 in _multicall
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/pluggy/_manager.py", line 115 in _hookexec
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/pluggy/_hooks.py", line 493 in __call__
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/_pytest/config/__init__.py", line 169 in main
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/_pytest/config/__init__.py", line 192 in console_main
  File "/Users/runner/work/black-it/black-it/.tox/py310/bin/pytest", line 8 in <module>
```

Therefore, the current workaround we adopted was to downgrade the version of the macos runner to the previous version, 11.
marcofavoritobi added a commit to bancaditalia/black-it that referenced this issue Dec 7, 2023
This change was needed because of a nondeterminism in how the macos-12 (=macos-latest at the time of writing) runner image was instantiated by GitHub Actions.
In particular, for runner version 2.311.0, the operating system was nondeterministically chosen between 12.6.9 and 12.7.1, as it can be seen in these two GH runs:
- https://github.com/bancaditalia/black-it/actions/runs/7128997647/job/19412070642
- https://github.com/bancaditalia/black-it/actions/runs/7128997647/job/19412070868

This is a known issue in the community: see actions/runner-images#8642

Furthermore, at the time of writing, it is suspected that Python code that uses pytables is not stable over macos at version 12.7.1 (but this problem does not occur on v12.6.9!), as witnessed by this issue: PyTables/PyTables#1093

What happened in our CI workflow is that tests resulted in a flaky outcome, but not because of our tests, but due to the nondeterminism in how the macos runner was instantiated by GitHub Actions.

This was not our unique attempt. In fact, we first tried to improve the preliminary configuration steps for the testing environment, as follows:
- if: matrix.os == 'macos-latest'
      name: Install dependencies (macos-latest)
      run: |
        # for some reason this seems to be a necessary step for MacOS images, but not for Ubuntu and Windows
        brew install hdf5
        brew install c-blosc
        # https://stackoverflow.com/questions/73029883/could-not-find-hdf5-installation-for-pytables-on-m1-mac
        echo "HDF5_DIR=/usr/local/" >> $GITHUB_ENV
        echo "BLOSC_DIR=/usr/local/" >> $GITHUB_ENV

This attempt consisted in installing HDF5 and C-blosc explicitly in the preliminary steps on CI for MacOS images. By the way, this step was part of the installation instructions of PyTables v3.9.2: https://github.com/PyTables/PyTables/blob/v3.9.2/README.rst#installation , although it seems this step is not actually needed.
Moreover, as explained here: https://stackoverflow.com/questions/73029883/could-not-find-hdf5-installation-for-pytables-on-m1-mac, sometimes must be explicitly set the environment path variables where HDF5 ahd C-blosc are installed
For some reason this is not needed on Ubuntu and Windows runners.

However, despite our efforts in this direction, the issue with pytables persisted. From the logs of the CI: (https://github.com/bancaditalia/black-it/actions/runs/7121188681/job/19389914846?pr=78#step:5:62)

```
Fatal Python error: Illegal instruction

Current thread 0x000000011783c600 (most recent call first):
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/tables/node.py", line 246 in __init__
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/tables/leaf.py", line 264 in __init__
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/tables/carray.py", line 200 in __init__
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/tables/earray.py", line 143 in __init__
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/tables/file.py", line 1345 in create_earray
  File "/Users/runner/work/black-it/black-it/black_it/utils/json_pandas_checkpointing.py", line 211 in save_calibrator_state
  File "/Users/runner/work/black-it/black-it/tests/test_utils/test_pandas_json_checkpointing.py", line 58 in test_save_and_load_calibrator_state
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/_pytest/python.py", line 194 in pytest_pyfunc_call
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/pluggy/_callers.py", line 77 in _multicall
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/pluggy/_manager.py", line 115 in _hookexec
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/pluggy/_hooks.py", line 493 in __call__
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/_pytest/python.py", line 1792 in runtest
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/_pytest/runner.py", line 169 in pytest_runtest_call
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/pluggy/_callers.py", line 77 in _multicall
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/pluggy/_manager.py", line 115 in _hookexec
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/pluggy/_hooks.py", line 493 in __call__
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/_pytest/runner.py", line 262 in <lambda>
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/_pytest/runner.py", line 341 in from_call
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/_pytest/runner.py", line 261 in call_runtest_hook
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/_pytest/runner.py", line 222 in call_and_report
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/_pytest/runner.py", line 133 in runtestprotocol
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/_pytest/runner.py", line 114 in pytest_runtest_protocol
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/pluggy/_callers.py", line 77 in _multicall
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/pluggy/_manager.py", line 115 in _hookexec
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/pluggy/_hooks.py", line 493 in __call__
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/_pytest/main.py", line 350 in pytest_runtestloop
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/pluggy/_callers.py", line 77 in _multicall
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/pluggy/_manager.py", line 115 in _hookexec
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/pluggy/_hooks.py", line 493 in __call__
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/_pytest/main.py", line 325 in _main
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/_pytest/main.py", line 271 in wrap_session
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/_pytest/main.py", line 318 in pytest_cmdline_main
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/pluggy/_callers.py", line 77 in _multicall
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/pluggy/_manager.py", line 115 in _hookexec
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/pluggy/_hooks.py", line 493 in __call__
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/_pytest/config/__init__.py", line 169 in main
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/_pytest/config/__init__.py", line 192 in console_main
  File "/Users/runner/work/black-it/black-it/.tox/py310/bin/pytest", line 8 in <module>
```

Therefore, the current workaround we adopted was to downgrade the version of the macos runner to the previous version, 11.
@DeeDeeG
Copy link

DeeDeeG commented Dec 13, 2023

The link for the image seems to be broken as well: https://github.com/actions/runner-images/releases/tag/macOS-12%2F20231017.6 vs. https://github.com/actions/runner-images/releases/tag/macOS-12%2F20230921.4 .

I can confirm this is still happening, the links being broken for (some?) macOS 12 runners.

It is somewhat troublesome for me when the links are broken/docs aren't available for the runner version, since I'm trying to debug some obscure failures in my app that are only happening in the CI context, and I can't review documentation of which software is on the runner, so debugging is much harder. For example, knowing the Python version is very helpful, but I will probably have to throw some which -a python3 into my workflow yaml to find this out, and so on for every tool I want to know which version is in the runner.

The usual documentation here is very strong, so not having access to it makes me appreciate what is usually there all the more, and miss it in its absence. Thanks for all your work on GitHub Actions / Azure DevOps. I hope this aspect of the missing/broken documentation (+ links) can be resolved. Thank you for considering.

@joepeding
Copy link

I'm running into this issue too. I have a workflow to build my library for and run tests on MacOS; but it requires installing MySQL 8.1. Something as simple as brew install mysql@8.1 worked for a while, but recently broke.

Rerunning the same workflow, I see versions 12.6.9 and 12.7.1 and 12.7.2 and it only gets past the brew install mysql@8.1 step on 12.6.9; but this took me 3 succesful and 6 failing runs to work out.

@hluaces
Copy link

hluaces commented Dec 18, 2023

Most of my jobs are using old images (20231029) which break all my workflows. This has been happening ever since #8730 was closed.

tbaudier added a commit to OpenGATE/opengate that referenced this issue Dec 20, 2023
According to
actions/runner-images#8642
actions/runner-images#8649

the macos runners are evolving leading to error of VM

It seems there is no problem with macos-11
@mikhailkoliada
Copy link
Member

The problem have been resolved now, sorry for inconvenience!

@jan-janssen
Copy link

At least for me the issue is not fixed. I see randomly crashing tests in pyiron/pympipool#243 . At the moment I cannot identify an obvious difference between the tests which work and those which do not work. My tests use the message passing interface (MPI) for internal communication. As a consequence, my tests rely on consistent network configuration, still at the moment it seems the network configuration of the hosts changes which at least I cannot verify based on the logs. This is just an assumption, but maybe others who also struggle with this issue can confirm that their tests also rely on a consistent network configuration and an inconsistent network configuration can lead to their tests failing randomly. Once more I want to emphasise that I have not experienced any similar issues on Linux or Windows tests environments.

@tmota900
Copy link

Still happening here too, having issues in some sort of volume binding when building dmg files:

An unhandled rejection has occurred inside Forge:
Error: Cannot find module '../build/Release/volume.node'
Require stack:
- /Users/runner/work/creator/creator/node_modules/.pnpm/macos-alias@0.2.11/node_modules/macos-alias/lib/create.js
- /Users/runner/work/creator/creator/node_modules/.pnpm/macos-alias@0.2.11/node_modules/macos-alias/index.js
- /Users/runner/work/creator/creator/node_modules/.pnpm/ds-store@0.1.6/node_modules/ds-store/index.js
- /Users/runner/work/creator/creator/node_modules/.pnpm/appdmg@0.6.6/node_modules/appdmg/lib/appdmg.js
- /Users/runner/work/creator/creator/node_modules/.pnpm/appdmg@0.6.6/node_modules/appdmg/index.js
- /Users/runner/work/creator/creator/node_modules/.pnpm/electron-installer-dmg@4.0.0/node_modules/electron-installer-dmg/src/index.js
- /Users/runner/work/creator/creator/node_modules/.pnpm/@electron-forge+maker-dmg@6.1.1/node_modules/@electron-forge/maker-dmg/dist/MakerDMG.js
- /Users/runner/work/creator/creator/node_modules/.pnpm/@electron-forge+core@6.1.1/node_modules/@electron-forge/core/dist/util/require-search.js
- /Users/runner/work/creator/creator/node_modules/.pnpm/@electron-forge+core@6.1.1/node_modules/@electron-forge/core/dist/util/plugin-interface.js
- /Users/runner/work/creator/creator/node_modules/.pnpm/@electron-forge+core@6.1.1/node_modules/@electron-forge/core/dist/util/forge-config.js
- /Users/runner/work/creator/creator/node_modules/.pnpm/@electron-forge+core@6.1.1/node_modules/@electron-forge/core/dist/util/index.js
- /Users/runner/work/creator/creator/node_modules/.pnpm/@electron-forge+core@6.1.1/node_modules/@electron-forge/core/dist/api/index.js
- /Users/runner/work/creator/creator/node_modules/.pnpm/@electron-forge+cli@6.1.1/node_modules/@electron-forge/cli/dist/electron-forge-publish.js
at Module._resolveFilename (node:internal/modules/cjs/loader:946:15)
    at Module._load (node:internal/modules/cjs/loader:787:27)
    at Module.require (node:internal/modules/cjs/loader:1012:19)
    at require (node:internal/modules/cjs/helpers:102:18)
    at Object.<anonymous> (/Users/runner/work/creator/creator/node_modules/.pnpm/macos-alias@0.2.11/node_modules/macos-alias/lib/create.js:7:13)
    at Module._compile (node:internal/modules/cjs/loader:1112:14)
    at Module._extensions..js (node:internal/modules/cjs/loader:1[166](https://github.com/clutch-creator/creator/actions/runs/7338689671/job/19981604048#step:8:167):10)
    at Module.load (node:internal/modules/cjs/loader:988:32)
    at Module._load (node:internal/modules/cjs/loader:834:12)
    at Module.require (node:internal/modules/cjs/loader:1012:19)
    at require (node:internal/modules/cjs/helpers:102:18)
    at Object.<anonymous> (/Users/runner/work/creator/creator/node_modules/.pnpm/macos-alias@0.2.11/node_modules/macos-alias/index.js:1:18)
    at Module._compile (node:internal/modules/cjs/loader:1112:14)
    at Module._extensions..js (node:internal/modules/cjs/loader:1166:10)
    at Module.load (node:internal/modules/cjs/loader:988:32)
    at Module._load (node:internal/modules/cjs/loader:834:12)
 ELIFECYCLE  Command failed with exit code 1.


 This came from original issue #8796 which the workaround I found is no longer working.

@mikhailkoliada
Copy link
Member

mikhailkoliada commented Dec 27, 2023

@tmota900 please report to npm directly, we are unlikely to help with the external rpm dependencies

muxator pushed a commit to bancaditalia/black-it that referenced this issue Feb 23, 2024
This change was needed because of a nondeterminism in how the macos-12 (=macos-latest at the time of writing) runner image was instantiated by GitHub Actions.
In particular, for runner version 2.311.0, the operating system was nondeterministically chosen between 12.6.9 and 12.7.1, as it can be seen in these two GH runs:
- https://github.com/bancaditalia/black-it/actions/runs/7128997647/job/19412070642
- https://github.com/bancaditalia/black-it/actions/runs/7128997647/job/19412070868

This is a known issue in the community: see actions/runner-images#8642

Furthermore, at the time of writing, it is suspected that Python code that uses pytables is not stable over macos at version 12.7.1 (but this problem does not occur on v12.6.9!), as witnessed by this issue: PyTables/PyTables#1093

What happened in our CI workflow is that tests resulted in a flaky outcome, but not because of our tests, but due to the nondeterminism in how the macos runner was instantiated by GitHub Actions.

This was not our unique attempt. In fact, we first tried to improve the preliminary configuration steps for the testing environment, as follows:
- if: matrix.os == 'macos-latest'
      name: Install dependencies (macos-latest)
      run: |
        # for some reason this seems to be a necessary step for MacOS images, but not for Ubuntu and Windows
        brew install hdf5
        brew install c-blosc
        # https://stackoverflow.com/questions/73029883/could-not-find-hdf5-installation-for-pytables-on-m1-mac
        echo "HDF5_DIR=/usr/local/" >> $GITHUB_ENV
        echo "BLOSC_DIR=/usr/local/" >> $GITHUB_ENV

This attempt consisted in installing HDF5 and C-blosc explicitly in the preliminary steps on CI for MacOS images. By the way, this step was part of the installation instructions of PyTables v3.9.2: https://github.com/PyTables/PyTables/blob/v3.9.2/README.rst#installation , although it seems this step is not actually needed.
Moreover, as explained here: https://stackoverflow.com/questions/73029883/could-not-find-hdf5-installation-for-pytables-on-m1-mac, sometimes must be explicitly set the environment path variables where HDF5 ahd C-blosc are installed
For some reason this is not needed on Ubuntu and Windows runners.

However, despite our efforts in this direction, the issue with pytables persisted. From the logs of the CI: (https://github.com/bancaditalia/black-it/actions/runs/7121188681/job/19389914846?pr=78#step:5:62)

```
Fatal Python error: Illegal instruction

Current thread 0x000000011783c600 (most recent call first):
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/tables/node.py", line 246 in __init__
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/tables/leaf.py", line 264 in __init__
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/tables/carray.py", line 200 in __init__
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/tables/earray.py", line 143 in __init__
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/tables/file.py", line 1345 in create_earray
  File "/Users/runner/work/black-it/black-it/black_it/utils/json_pandas_checkpointing.py", line 211 in save_calibrator_state
  File "/Users/runner/work/black-it/black-it/tests/test_utils/test_pandas_json_checkpointing.py", line 58 in test_save_and_load_calibrator_state
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/_pytest/python.py", line 194 in pytest_pyfunc_call
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/pluggy/_callers.py", line 77 in _multicall
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/pluggy/_manager.py", line 115 in _hookexec
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/pluggy/_hooks.py", line 493 in __call__
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/_pytest/python.py", line 1792 in runtest
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/_pytest/runner.py", line 169 in pytest_runtest_call
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/pluggy/_callers.py", line 77 in _multicall
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/pluggy/_manager.py", line 115 in _hookexec
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/pluggy/_hooks.py", line 493 in __call__
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/_pytest/runner.py", line 262 in <lambda>
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/_pytest/runner.py", line 341 in from_call
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/_pytest/runner.py", line 261 in call_runtest_hook
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/_pytest/runner.py", line 222 in call_and_report
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/_pytest/runner.py", line 133 in runtestprotocol
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/_pytest/runner.py", line 114 in pytest_runtest_protocol
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/pluggy/_callers.py", line 77 in _multicall
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/pluggy/_manager.py", line 115 in _hookexec
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/pluggy/_hooks.py", line 493 in __call__
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/_pytest/main.py", line 350 in pytest_runtestloop
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/pluggy/_callers.py", line 77 in _multicall
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/pluggy/_manager.py", line 115 in _hookexec
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/pluggy/_hooks.py", line 493 in __call__
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/_pytest/main.py", line 325 in _main
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/_pytest/main.py", line 271 in wrap_session
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/_pytest/main.py", line 318 in pytest_cmdline_main
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/pluggy/_callers.py", line 77 in _multicall
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/pluggy/_manager.py", line 115 in _hookexec
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/pluggy/_hooks.py", line 493 in __call__
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/_pytest/config/__init__.py", line 169 in main
  File "/Users/runner/work/black-it/black-it/.tox/py310/lib/python3.10/site-packages/_pytest/config/__init__.py", line 192 in console_main
  File "/Users/runner/work/black-it/black-it/.tox/py310/bin/pytest", line 8 in <module>
```

Therefore, the current workaround we adopted was to downgrade the version of the macos runner to the previous version, 11.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests