Controlling access to macOS large runners for GitHub Actions

In 2023, GitHub introduced new powerful macOS runners for GitHub Actions. These runners have a considerable higher amount of processors / memory and disk space allocated to them to speed up the execution of workflows. This advantage comes at a cost though, as billing per minute of executed workflow time is considerably higher as compared to normal runners (see billing for runners), on top of the usual minute multiplier for macOS runners (each minute of executed workflow time on a macOS runner counts as 10 minutes for billing purposes).

Going to speed up

In order to use such a macOS large runner, you can simply add a runs-on: <runner-type> to your job definition, e.g. using macos-latest-large as runner type:

name: learn-github-actions-testing
on: [push]
jobs:
  build:
    runs-on: macos-latest-large
    steps:
      - uses: actions/checkout@v4
      - name: Build
        run: swift build
      - name: Run tests
        run: swift test

Additionally, your organization needs to have a GitHub Team or GitHub Enterprise Cloud plan to be able to use such a macOS large runner (which is now the case for all Eclipse projects hosted on GitHub as of 2024), otherwise workflows using such a runner will fail to run. Once your organization is eligible to use large runners, you probably want to control the access to such runners for the repositories in your organization to avoid surprises when you receive your next invoice. GitHub offers a convenient way to define runner groups to control which repositories can access such large runners.

What the …

Unfortunately, such runner groups can only be defined for linux and windows runners, there is simply no way to prevent that macOS large runners are being used by any of your repositories once their use is configured in a workflow as described above. This poses a problem for non-profit organizations (like the Eclipse Foundation) that host a lot of projects and their associated repositories on GitHub as it might result in higher than expected billing expenses as some projects try using such large runners to speed up their workflows without realizing the consequences.

While it is possible to monitor the incurred costs of using GitHub Action minutes, this is a tedious and manual task and requires communication with projects to change their workflows if occurrences have been identified.

Gaming the system

The idea was born to add some automation to prevent the execution of workflows on such macOS large runners unless the project / repository is entitled to use such a runner.

After studying the available GitHub Rest API and preliminary testing, we figured out the following logic reliably prevents the execution of workflows on macOS large runners:

• listen to workflow_job events with action queued
• check whether the included workflow_job object has labels that indicate that the job is supposed to run on a macOS large runner
• if the above evaluates to true and the repository is not eligible to use such a runner, cancel the workflow_run

To receive the necessary webhook events from GitHub in case a workflow is being queued to run, you have to set up an organization or repository webhook, listen for the event and apply the logic.

All good

At the Eclipse Foundation we are operating an open-source project called Otterdog in order to configure our numerous organizations and repositories hosted on GitHub at scale. This tool is effectively a GitHub App and is installed for all our projects / organizations on GitHub and already can listen to various events sent from GitHub. So naturally we added the above logic to this tool and allowed to define which organizations are allowed to use such large runners via a configuration file (see this example).

This allows us to control the use of macOS large runners which unfortunately is not yet possible through any of the administration consoles at GitHub. On the other hand, our implemented workaround showcases the power of GitHub Apps on how you can utilize them to adjust your GitHub experience to your organizational needs.

If you are member of an Eclipse project and would like to utilize macOS large runners for your workflows, reach out to us via the HelpDesk.