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>
The next time we update the toolchain, all of the CI
Actions will automatically use it when go.mod is updated.
Signed-off-by: Denton Gentry <dgentry@tailscale.com>
Linux-only for now, to avoid having to figure out why
powershell doesn't like my shell scripting. (Not that I blame it.)
That'll be enough to catch most regressions.
Fixes#1083
Co-authored-by: Aaron Klotz <aaron@tailscale.com>
Signed-off-by: Josh Bleecher Snyder <josh@tailscale.com>
In prep for using 1.17 features.
Note the go.mod changes are due to:
https://golang.org/doc/go1.17#go-command
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
#1817 removed the only place in our CI where we executed our benchmark code.
Fix that by executing it everywhere.
The benchmarks are generally cheap and fast,
so this should add minimal overhead.
Signed-off-by: Josh Bleecher Snyder <josharian@gmail.com>
