I've done some experimentation on Azure Pipelines and it's very similar to actions. What a surprise...

Here's a process tree I captured

Found process: Win32_Process: powershell.exe (Handle = "4012")
Found process: Win32_Process: powershell.exe (Handle = "3992")
Found process: Win32_Process: Agent.Worker.exe (Handle = "840")
Found process: Win32_Process: Agent.Listener.exe (Handle = "5968")
Found process: Win32_Process: provisioner.exe (Handle = "5476")
Found process: Win32_Process: svchost.exe (Handle = "1756")
Found process: Win32_Process: services.exe (Handle = "728")
Found process: Win32_Process: wininit.exe (Handle = "592")

If you run this a few times in the same job then everything before Agent.Worker.exe changes each time. This quite closely mirrors GtiHub Actions where you get a Runner.Worker.exe and Runner.Listener.exe process. The "worker" lives for the length of one job, and the "listener" persists between multiple jobs (at least on a self-hosted runner).

This PR just updates our current detection of GH Actions to also detect Azure Pipelines.

This will be a benefit because I think with the current default of just going down three processes it'll hit Agent.Listener.exe and this isn't what we want for self-hosted runners as it'll affect the next job as well. For cloud-hosted it doesn't matter as the whole VM is wiped.

Merge / deployment checklist

• Confirm this change is backwards compatible with existing workflows.
• Confirm the readme has been updated if necessary.