Automatically spin up a self-hosted ARM64 runner as needed

When we receive an event indicating that a workflow job was queued that
requires a Windows/ARM64 runner, let's let our automation do its magic
and create a new such runner.

It does take a bit of patience to do it this way: whenever a new
workflow job is queued, it takes about 7-8 minutes to create the new
runner.

An alternative would be to pre-allocate runner VMs, and immediately
deallocate them to await being started when needed. But even that
start-up time takes a couple of minutes and would not be immediate.
Besides, it would cost quite a lot more Azure credits: merely keeping
around a fast disk has a non-negligible cost.

Yet another alternative would be to pre-allocate runner VMs and keep
them running. However, that way we would quite handily run through all
of the monthly-available Azure credits in no time.

So let's just go with the 7-8 minutes solution, it's not like we're
intending to run many more than a dozen Windows/ARM64 builds per month.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Author: dscho

GitForWindowsHelper/self-hosted-arm64-runners.js

@@ -35,5 +35,23 @@ module.exports = async (context, req) => {
         throw new Error(`${sender} is not allowed to do that`)
     }
 
+    if (action === 'queued') {
+        // Spin up a new runner
+        const triggerWorkflowDispatch = require('./trigger-workflow-dispatch')
+        const token = await getToken()
+        const answer = await triggerWorkflowDispatch(
+            context,
+            token,
+            'git-for-windows',
+            'git-for-windows-automation',
+            'create-azure-self-hosted-runners.yml',
+            'main', {
+                runner_scope: 'repo-level'
+            }
+        )
+
+        return `The workflow run to create the self-hosted runner VM was started at ${answer.html_url}`
+    }
+
     return `Unhandled action: ${action}`
 }