Questions about MacOS self-hosted runners

Hey guys!

I have a few questions about usage of self-hosted runners with Github Actions, mostly concerning MacOS. We have been using three x64 machines before, but lately got also a single one with M1 chip, and here where questions come from.

Prerequisite - with introduction of this M1 machine, we would like to run some jobs in the shared pool between both x64 and m1 machines, since these jobs are agnostic of architecture and there’s no need to limit the pool.

Question 1

Is there a way to add macOS-ARM runner as an actual ARM?

Currently there is only one version of runner application available for macs - x64:

No matter how hard I fiddle with rosetta when setting running this app, it still labels my machine as X64, which makes it impossible to filter it unless assigning custom label:

With other machines being “real X64”:

If I only want to select this specific machine, it will work, because of cumulative labels, but if I want to select “any X64 machine belonging to ui-platform”, I am out of luck.

Can we fix the runner application to set the correct architecture?

Question 2

Is there a way to run a job for “any architecture” but scoped for a custom label?

Currently we run jobs like this, with the latest label separating our machines from machines of another team in the same org.

  my-job:
    runs-on: [self-hosted, macOS, X64, ui-platform]

I could change it to the following, however it would “unscope” my machines to the level of entire organisation, and will schedule runs on machines we do not own.

  my-job:
    runs-on: [self-hosted, macOS]

It would be better to have a better control over labelling with something like the following.

  my-job:
    runs-on:
       - machine: [self-hosted, macOS] <- this uses a cumulative subset of default labels
         with: 
            labels: [ui-platform] <- this uses a cumulative subset of custom labels

Question 3

Is there a way to invalidating cache between different architectures?

If we look at most of the examples of creating caches using actions/cache, they operate using runner.os as a prefix for a cache key.

key: ${{ runner.os }}-yarn-${{ hashFiles('**/yarn.lock') }}

Now generally this is not a problem, however when using shared pool for the same job, I would assume that a case for sharing cache between x64 and arm64 machines is not something what would work for every case, hence we need something like following.

key: ${{ runner.os }}-{{ runner.arch }}-yarn-${{ hashFiles('**/yarn.lock') }}

Which current runner context object does not provide:

Alternatively runner.os could become less ambiguous and include architecture into the name of OS.

Looking forward to feedback
Thanks!

2 Likes
  1. The Actions runner still seems to be missing ARM support, which occurs to me as the pre-requisite for what you want to do:

    Add ARM + MacOS target to be able to use on self-hosted runners · Issue #805 · actions/runner · GitHub

  2. The concept of labels for scoping seems familiar to me from Jenkins, but I haven’t seen anything like that for GitHub Actions. I suggest you get in touch with support about this as this is a feature request:

    If you have feedback or feature requests for GitHub Actions, share those in the Feedback form for GitHub Actions.

  3. I would hope that a context variable arch is added when ARM support lands. Otherwise, setting an env variable in the workflow before the caching and then using it like ${{ env.ARCH }} may also work.