mirror of
https://github.com/tailscale/tailscale.git
synced 2026-10-08 11:21:51 -04:00
Brad Fitzpatrick
574ef3b2a8
The natlab-basic workflow builds the gokrazy natlab image in its own step so that the test's rebuild of it (vmtest always rebuilds, so the baked-in binaries match the source under test) is a build cache hit rather than a cold build inside go test's -timeout budget. That never worked: the Makefile ran whatever "go" was on $PATH, the runner's stock Go, while the go command puts its own $GOROOT/bin first on the test binary's $PATH, so the rebuild from inside "go test" used tailscale/go. GOCACHE entries embed the compiler's build ID, so the step warmed nothing. In practice the in-test rebuild took about 2.5 minutes of the 3 minute -timeout, leaving TestEasyEasy about 20 seconds for booting two VMs, logging in, and pinging. A passing run on main took 167s. Any hiccup in the remaining budget, such as the "tailscale up" hang fixed separately, ended in go test's timeout panic with no useful output. Make the natlab targets in gokrazy/Makefile use ../tool/go so the step and the test use the same toolchain and cache. Fix the same mistake in natlab-test.yml's cache warming step, whose comment documented the wrong belief about which toolchain the in-test builds use. Raise natlab-basic's -timeout to match natlab-test.yml so that a hang fails through vmtest's own bounded waits (which dump the node's logs) instead of through go test's timeout panic (which dumps nothing about the VMs). Updates #13038 Updates #deflake Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com> Change-Id: Iaa6085ec5aa029373204baf75b169ff375c2b355