Ephemeral (single use) runner registrations

Describe the bug When starting a self hosted runner with ./run.cmd --once, the runner sometimes accepts a second job before shutting down, which causes that second job to fail with the message:

The runner: [runner-name] lost communication with the server. Verify the machine is running and has a healthy network connection.

This looks like the same issue recently fixed here: microsoft/azure-pipelines-agent#2728

To Reproduce Steps to reproduce the behavior:

1. Create a repo, enable GitHub Actions, and add a new workflow

2. Configure a new runner on your machine

3. Run the runner with ./run.cmd --once

4. Queue two runs of your workflow

5. The first job will run and the runner will go offline

6. (Optionally) configure and start a second runner

7. The second job will time out after several minutes with the message:

   The runner: [runner-name] lost communication with the server. Verify the machine is running and has a healthy network connection.
   

   (where [runner-name] is the name of the first runner)

8. Also: trying to remove the first runner with the command ./config.cmd remove --token [token] will result in the following error until the second job times out:

   Failed: Removing runner from the server
   Runner "[runner-name]" is running a job for pool "Default"
   

Expected behavior The second job should run on (and wait for) any new runner that comes online rather than try to run as a second job on the, now offline, original runner.

Runner Version and Platform

2.262.1 on Windows

Runner and Worker’s Diagnostic Logs

_diag.zip

[rclmenezes]

Help us @bryanmacfarlane, you’re our only hope! 🙏

[bryanmacfarlane]

@rclmenezes ack on #1 and #2. we’re currently designing and working on it. The plan is exactly what you laid out, register the runner ephemeral with the backend service so the service auto cleans it up after the job is complete and the runner / container exits.