Github self hosted runners per branch - github-actions-self-hosted-runners

Question

I'm trying to implement Github self hosted runner, but I've hit the wall hard
I want to have different runners for my prod and dev servers
For what I understand, it's possible to set labels depending on the environment, but both my dev and prod servers are essentially the same (both are windows server 20012 R2, with similar hardware)
I have two yml files pointing to dev and master respective, but can I point the runner to the right action?
I've tried to add a label to the runners like this:
But when I publish to master, the top runner is triggered
The yml file for prod looks something like this:
name: SSR-Prod
on:
push:
branches: [master]
pull_request:
branches: [master]
jobs:
build:
runs-on: self-hosted
steps:
- uses: actions/checkout#v2
- name: Restore dependencies
run: npm install
- name: Build and publish
run: npm run build:ssr

Answer 1

You need to specify enough labels to select correct runner, like so:
runs-on: [ self-hosted, master ]
This will make sure your workflow runs on second runner.

Answer 2

I actually found that #frennky's answer didn't seem to work for us; spent a lot of time ripping hair out (fortunately, I have a lot). What did work was this:
It's easy to do, actually, but finding out how is oddly difficult.
The documentation is marvelous at telling you all the options, but not always great for giving examples.
For us, what worked was this:
setup-dns:
name: Setup dynamic DNS
runs-on: prod
Assuming, of course, that your label is 'prod'. (BTW, don't make Prod use dynamic DNS). According to the docs and common sense, this should work:
setup-dns:
name: Setup dynamic DNS
runs-on: [self-hosted, prod]
But it does not; the runner never runs. I did have a conversation with GitHub support but I've lost the link. As long as you don't create a self-hosted runner with a label (not name) of 'ubuntu-latest' (or other GitHub hosted runner O/S versions) you won't have a problem!
When you think about it logically, putting in your own label requires that it's a self-hosted runner, so the two values for "runs-on" are somewhat redundant. My guess is that you could still use two self-hosted runner labels, and the routine would run on whichever one was available. We didn't go that route as we needed patches run on multiple production servers deterministically, so we literally have prod1, prod2, prod2, etc.
Now here's where it gets interesting. Let's say that you have a callable workflow - better known as a "Subroutine". In that case, you cannot use "runs-on" in the caller; only the callee.
So here's what you do, in your callable workflow:
on:
workflow_call:
inputs:
target_runner_label:
type: string
description: 'Target GitHub Runner'
required: true
# not strictly needed, but great for testing your callable workflow
workflow_dispatch:
inputs:
target_runner_label:
type: string
description: 'Target GitHub Runner'
required: true
jobs:
report_settings:
name: Report Settings
runs-on: ${{ inputs.target_runner_label || github.event.inputs.target_runner_label }}
Now - you might wonder at the || statement in the middle. It turns out, the syntax for referring to workflow_call inputs and workflow_dispatch inputs are completely different.
Another gotcha: The 'name' of the runner is completely superfluous, because it's the label, not the name, that the workflow uses to trigger it. In the below example, you wouldn't use "erpnext_erpdev" to trigger the workflow, you'd use "erp_fix"