1. Use buildjet for the longer Linux CI workflows.
2. Continue with `ubuntu-latest` for shorter Linux CI workflows.
3. Use a large GitHub-hosted Windows runner.
https://docs.github.com/en/actions/using-github-hosted-runners/using-larger-runners
4. Make CIFuzz run on merge to main or release branch, not
in the pull request
Two runs each of the original workflow files and the updated
workflows in this PR. One run of the GitHub Large Ubuntu runners
is included; these are clearly between the regular GitHub and BuildJet
runners in performance.
GitHub GitHub BuildJet BuildJet GHLarge
codeql-analysis.yml 4m 30s cached 2m 56s 2m 59s 4m 0s
cross-darwin.yml 3m 10s 3m 19s 1m 33s 1m 30s 2m 43s
cross-freebsd.yml 3m 33s 3m 10s 1m 28s 1m 22s 2m 15s
cross-openbsd.yml 3m 4s 2m 36s 1m 29s 1m 22s 2m 3s
cross-wasm.yml 1m 59s 2m 2s 1m 12s 1m 16s 1m 46s
cross-windows.yml 2m 45s 3m 0s 1m 44s 1m 25s 2m 6s
linux32.yml 4m 27s 4m 0s 1m 55s 2m 8s 2m 51s
linux-race.yml 3m 54s 4m 7s 2m 22s 2m 12s 3m 14s
linux.yml 4m 23s 4m 39s 2m 37s 2m 15s 3m 38s
static-analysis.yml
/vet 1m 41s 2m 22s 52s 56s 1m 12s
/staticcheck(linux, amd64) 2m 47s 2m 38s 1m 7s 1m 10s 1m 52s
/staticcheck(windows, amd64) 2m 5s 2m 4s 1m 6s 1m 8s 1m 33s
/staticcheck(darwin, amd64) 2m 14s 2m 20s 1m 10s 1m 10s 1m 50s
/staticcheck(windows, 386) 2m 36s 1m 58s 1m 23s 1m 8s 1m 39s
vm.yml 1m 30s 1m 32s 2m 31s 2m 23s N/A
A few very short workflows are being left on GitHub-hosted runners, like
licenses and gofmt. These benefit from the quicker dispatch to GitHub
hosted runners.
--------
For Windows and the windows.yml test run:
- the regular `windows-latest` runner takes about 6 minutes 20 seconds
- there is enough variability run to run that we get the same ~4 minute
run with:
- a GitHub-hosted large runner
- a self-hosted Windows Server 2022 in an AWS t3.xlarge
- a self-hosted Windows Server 2022 in an AWS c6i.xlarge
Since there is not a gain from operating our own runner, we'll pay
GitHub to operate a Windows large runner.
Signed-off-by: Denton Gentry <dgentry@tailscale.com>