Test with M1 macOS CI runner by EliahKagan · Pull Request #1817 · gitpython-developers/GitPython (original) (raw)

This adds CI test jobs that run on ARM processors. Specifically, it adds macos-14 as a value for os in the CI test matrix. The new macOS 14 runners use Apple Silicon M1 systems (64-bit ARM CPUs), allowing GitPython to be tested on AArch64/ARM64 actions/python-versions builds of Python, such as python-3.12.1-darwin-arm64.tar.gz.

Not all versions of Python that GitPython supports are currently available via actions/setup-python:

Python 3.7 builds that can run on macos-14 runners are unlikely ever to be available, because 3.7 is end-of-life.
Python 3.8 and Python 3.9 builds are currently unavailable, but this may be remedied; it is being tracked in Python <3.10 not available on new macOS M1 runners actions/setup-python#808.

Therefore, the new macos-14 jobs this creates are only for Python 3.10, Python 3.11, and Python 3.12. This is achieved by using exclude for the earlier versions. This way, a macos-14 job would automatically be created when 3.13 is added to python-version. (The first commit doesn't exclude anything, to verify that 3.7, 3.8, and 3.9 error out as expected. Then the second commit adds the exclusions.) If this PR is accepted, then I recommend 3.8 and 3.9 be added later, if and when they become easily available.

This does not remove or change any pre-existing jobs, but maybe it should. That is to say that this does not change macos-13 to macos-14, but instead just adds three macos-14 jobs. All six of the old macos-13 jobs, which run on Intel-based macOS 14 runners, are retained. Having nine macOS jobs may be considered excessive; even if not, builds for Python 3.8 and 3.9 may become available, and having eleven may be considered excessive. Options include:

Rejecting or deferring this change completely.
Taking this it as is but revisiting the matter when builds of more Python versions become available.
Changing this to omit some versions. If that is done, the question is which ones. We could avoid doubling up Python version on macOS, but there may be a benefit to this, as it would make it easier to guess that a failure is related to the architecture. (Though we still would not know immediately because it is a different version of macOS as well.)