Investigate running on self-hosted runners

[russhwolf]

Some folks have asked about using self-hosted runners for the github action and mentioned running into issues. Naively there shouldn't be any difference, but we should give this a try internally and see if there's any changes we need to make to support it.

If you're trying this yourself and hit issues, feel free to leave details here.

[mdivkovic-speech]

Hi @russhwolf, my team needs this option. We have a Mac Mini build server in-house and want to use that as a runner. As you may know, building on a GitHub hosted Mac runner consumes 10x the credits that a Linux runner does, and we don't want to be limited by that.

My understanding is that you could modify your workflows to parametrize the runs-on statement, as described here.

on:
  workflow_call:
    inputs:
      runs-on:
        type: string
        default: '["windows-latest"]'
jobs:
  myjoba:
    runs-on: ${{fromJSON(inputs.runs-on)}}
    outputs:
      myout: myin
    steps:
    - run: echo Hello World

Calling it like this:

on: push
jobs:
  comp:
    name: comp-${{toJSON(strategy)}}
    uses: ChristopherHX/newcomposite-sample/.github/workflows/weirdworkflow.yml@reusable-workflows
    with:
      runs-on: '["self-hosted", "linux"]'

You could still keep macos-12 as the default, for those who want to use it with GitHub's runner.

Looking forward to your reply!

[russhwolf]

That sounds reasonable @mdivkovic-speech. I definitely would want to keep macos-12 as the default, but having the host as an optional parameter makes sense. Do you want to make a PR against KMMBridgeGithubWorkflow?

[russhwolf]

Did some testing here and I thought I had it working until I realized that github apparently limits self-hosted runners to only call reusable workflows from the same org. So I think there might actually not be anything that can be done here beyond just copying our workflow to your own repo and changing runs-on there.

I'm still going to add the parameter though because it might be useful for people who need to switch what macos version they run on.

[mdivkovic-speech]

@russhwolf sorry for the very late reply and thank you for the update!

To summarize:

• Your workflow will support the runs-on parameter, but within Touchlab's repo it will effectively only allow switching to a different GitHub hosted runner, e.g. to control the Mac OS version
• Integrators looking to use your workflow with a self hosted runner should copy it to their repo and call that copy instead

That about right?

[russhwolf]

Yeah, that's the best solution I see at the moment. I don't love it though. Definitely open to other ideas if people have them.

[kpgalligan]

I'm going to close this for now. Future version will be a much simpler default workflow.