Test new GitHub-hosted runners (OSOE-773)

[BenedekFarkas]

From the original announcement:

From now on, any Linux or Windows workflow triggered from a public repository, using GitHub’s default labels, will run on our faster, more powerful 4-vCPU runners.
...
This upgrade offers increased performance, memory, and storage with 4-vCPUs, 16 GiB of memory and 150GiB storage.

Jira issue

[BenedekFarkas]

This is a bit surprising (as in how low):

Through the rollout, we have seen real-world improvements of around 25% for GitHub Actions workflows on these new machines without any changes required from you as a developer.

The first full test comparing these runners:

• Root solution:
  • buildjet-4vcpu-ubuntu-2204: 15 minutes 10 seconds
  • ubuntu-22.04: 20 minute timeout
• NuGet solution:
  • buildjet-4vcpu-ubuntu-2204: 5 minutes 13 seconds
  • ubuntu-22.04: 7 minutes 3 seconds (doesn't look it changed meaningfully compared to previous average from 7-8 builds)
• NuGet solution on Windows (not fair comparison due to different core count):
  • gitrunners-windows-2022-x64-8vcpu: 21 minutes 53 seconds
  • windows-2022: 30 minute timeout

No need/sense to change anything now.

[Piedone]

Ah, awesome! It should be a lot more for us, and indeed it seems so. Roughly this is where we got this:

BuildJet is still better, but that's only Linux. GitRunners with Windows has an issue with long wait times though, sometimes even 15 minutes, which while technically doesn't count against the runtime, still makes you wait longer. Did you count that too?

Related: OrchardCMS/OrchardCore#12583 (comment)

[BenedekFarkas]

GitRunners with Windows has an issue with long wait times though, sometimes even 15 minutes, which while technically doesn't count against the runtime, still makes you wait longer. Did you count that too?

No, although I'm assuming queue times are quite varied. The concrete case I saw for this issue is that GitRunners runner started 2 and a half minutes after GitHub's own (for the same Windows build).

[Piedone]

OK!