Macos runner gives randomly Intel (x86) or M1 (arm64) and no way to get only Intel(x86)

[medyagh]

Describe the bug

We try to run functional test for minikube (using virtualbox) as seen here, how ever it randomly gives us either Arm64 or Intel CPU architecture and there is NO WAY for us to force it to give us only Intel
https://github.com/kubernetes/minikube/blob/5eecf3084f2487ceb3cebad33ddfe0006908c941/.github/workflows/pr.yml#L521
we use

runs-on: macos-12

To Reproduce

  functional_virtualbox_macos:
    permissions:
      contents: none
    needs: [build_minikube_test_binaries]
    env:
      TIME_ELAPSED: time
      JOB_NAME: "functional_virtualbox_macos"
      GOPOGH_RESULT: ""
      SHELL: "/bin/bash" # To prevent https://github.com/kubernetes/minikube/issues/6643
    runs-on: macos-12
    steps:
      - name: Check architecture
        shell: bash
        run: |
          if [ $(uname -m) != "x86_64" ] 
          then 
              echo "$(uname -m) detected. This test must be run on x86_64"
              exit -1
          fi
          exit 0

for the full yaml checkout https://github.com/kubernetes/minikube/blob/5eecf3084f2487ceb3cebad33ddfe0006908c941/.github/workflows/pr.yml#L521

Expected behavior

I expect it to give me the CPU architecture not randomly but through a tag such as Arch: x86

Runner Version and Platform

I am using whatever latest available public for free macos-12 agents.

OS of the machine running the runner? OSX/Windows/Linux/...

macos-12

What's not working?

We try to run minikube with Virtualbox but it fails because it gives us M1 Machines (arm64) and virtualbox only runs on intel.

Currently we are trying to implement a workaround that if we detect the CPU arch to be arm64 we Exit the test so at least it doenst fail, and we are planning to implement a cron job to keep triggering the test till it Gets the Right architecture, which is just a hack to get us going, and this is affecting anyone who uses macos runners, it is better to be fixed in github action runner for all users.

    runs-on: macos-13
    steps:
      - name: Check architecture
        shell: bash
        run: |
          if [ $(uname -m) != "x86_64" ] 
          then 
              echo "$(uname -m) detected. This test must be run on x86_64"
              exit -1
          fi
          exit 0

[ComradeProgrammer]

https://github.com/kubernetes/minikube/actions/runs/8472699544/job/23358462960?pr=18531
link to the incorrect github action run

[ChristopherHX]

https://github.com/kubernetes/minikube/actions/runs/8472699544/job/23358462960?pr=18531 link to the incorrect github action run

macos-14 (is latest now) in GitHub Actions is only available for arm64.

See here https://github.blog/changelog/2024-01-30-github-actions-introducing-the-new-m1-macos-runner-available-to-open-source, I fear that I have to rewrite my intel pipelines once macos-12/13 images are removed for GitHub Actions

The macos-14 intel image is exclusively used by azure devops pipelines hosted agents

[joffrey-bion]

@ChristopherHX even when I explicitly specify macos-12, I sometimes get Arm architectures (as stated in the issue description). Did you find a way to consistently get intel?

[ChristopherHX]

@joffrey-bion I'm unaffected
I would expect me beeing a target of ugly experiments with GitHub Free Plan, but I have never seen any macos-12 job running on m1 yet
Having multiple macos-12 cron jobs running on every morning, any failure I saw yet were caused by either qt5 download errors / hdiutil random failures
I'm pretty shure that a cmake call from a m1 mac will die during linking my app with x86_64 dependencies (don't use any xcompile flags)

This issue doesn't link any m1 macos-12/macos-13 job yet, maybe you can provide one?
Anyway I can't change anything here.

(larger paid runners with distinct labels like xlarge are arm64 pre macOS 14)

[joffrey-bion]

It looks like I misattributed the source of the error. I was getting errors related to colima / nested virtualization, and usually it's a sign it's running on ARM, and once I found this specific Github issue I didn't look further.

Now I added an architecture check and it turns out I'm I getting those failures on x86_64. They are different from plain missing support for nested virtualization. I will need to look into the actual cause. Thanks for making me double-check.

[nodeselector]

@medyagh @ComradeProgrammer 👋 Can you share recent examples of this happening? I don't have telemetry for the links that you shared due to telemetry aging off.