The action doesn't work with ARC runners on arm64

[hussein-awala]

Description:
I am currently in the process of migrating Apache Airflow CI to self-hosted runners running on a K8S cluster, which will be managed by an ARC. To set up the runners, I have opted to use the official Docker image summerwind/actions-runner:v2.306.0-ubuntu-20.04, and I have scheduled the pods on arm64 nodes.

Unfortunately, during the setup, I encountered the following error:

The version '3.8' with architecture 'arm64' was not found for Ubuntu 20.04.

To address this issue, I checked the versions manifest but did not find any file for the arm64 architecture with the platform set to ubuntu (btw it should be linux instead). It appears that all the arm64 files I found are for darwin, indicating that the action does not support arm64 on Linux:

runner@small-runners-deployment-dgvzj-9pxpg:/$ uname -a
Linux small-runners-deployment-dgvzj-9pxpg 5.10.184-175.731.amzn2.aarch64 #1 SMP Tue Jun 27 21:48:49 UTC 2023 aarch64 aarch64 aarch64 GNU/Linux

After testing some of the suggested solutions in issue #162, such as providing the environment variables AGENT_TOOLSDIRECTORY and RUNNER_TOOL_CACHE, it seems that they did not resolve the issue as expected.

As a temporary workaround, I opted to remove all usages of the action and instead installed Python directly in the runner Docker image. This allowed me to proceed with some tests successfully. However, I still require the action to install a different Python version for specific tests.

Action version:
Specify the action version

Platform:

• Ubuntu
• macOS
• Windows

Runner type:

• Hosted
• Self-hosted

Tools version:

all the versions

Repro steps:
To reproduce it, you can use the action inside a docker container created from the image ``summerwind/actions-runner:v2.306.0-ubuntu-20.04` and running on linux with arch arm64.

Expected behavior:
There should be a Python version available for Linux with arm64 architecture, and the action should be able to detect that it's running on Linux platform instead of Ubuntu.

Actual behavior:
It's possible that the action is already capable of detecting that it's running on Linux, and the mention of Ubuntu in the log message might be simply informational. But the main problem is there is no available version for Ubuntu/Linux with arm64, and this blocks me to check if the second issue exists or not.

[dusan-trickovic]

Hello @hussein-awala ! Thank you for reporting the issue, we will investigate it further and see what can be done :)

[V0lantis]

Hello, I found the issue by both running in local setup-python and reading the debug log from our actions. Python 3.x for linux arm is not available in python-version repository and therefore, not present in the manifest.

 ##[debug]check 3.11.4 satisfies 3.11
  ##[debug]arm64===arm64 && darwin===linux

The version present in the manifest is just for darwin. A pull request is already open for this in python-version, so maybe we should try to tell them that some runners are available with arm64 and linux?

[ilya-lavrenov]

maybe we should try to tell them that some runners are available with arm64 and linux?

arm64 runners are not required, because python can be cross-compiled from x86_64 to aarch64

[dboreham]

Hmm. Just ran into this, ironically while trying to spin up our CI environment in arm64 in order to shake out recurrent arm-incompatibilities that have been creeping into our stacks. But...another turtle layer because I can't even get CI to run because it uses setup-python. Has anyone figured out a workaround (other than just using the environmental Python, which isn't an option because we need to verify interop with 3.8 --- not the default install on any modern container)? Presumably the obvious way would be to fork python-versions, have it build the necessary releases, then fork this project (which afaik we already did somewhere) and have it point at the forked python-versions releases. Quite a bit of work, so if anyone has a better option...

[V0lantis]

Hmm. Just ran into this, ironically while trying to spin up our CI environment in arm64 in order to shake out recurrent arm-incompatibilities that have been creeping into our stacks. But...another turtle layer because I can't even get CI to run because it uses setup-python. Has anyone figured out a workaround (other than just using the environmental Python, which isn't an option because we need to verify interop with 3.8 --- not the default install on any modern container)? Presumably the obvious way would be to fork python-versions, have it build the necessary releases, then fork this project (which afaik we already did somewhere) and have it point at the forked python-versions releases. Quite a bit of work, so if anyone has a better option...

Yep, we use the following workaround :

      - if: ${{ matrix.arch == 'arm64' }}
        uses: deadsnakes/action@v2.1.1
        with:
          python-version: "3.11"
      - if: ${{ matrix.arch == 'amd64' }}
        uses: actions/setup-python@v4
        with:
          python-version: '3.11'
          cache: 'pip'

[dboreham]

Thank you for that! It was a bit of a tussle to get the deadsnakes action to run in our environment (it uses sudo, and trips over the tzdata package prompting for user input) but once those issues had been worked around, it's working!