ci: build and test warp on every push

[Ryanmello07]

warp is one of the urnetwork repos with no CI of its own. This adds the first one: a push, a PR against main, or a manual dispatch now compiles every package and runs the real test suite.

What it runs

On ubuntu-latest, with actions/checkout@v4 and actions/setup-go@v5 at go-version: stable — the same shape and the same pinning as the existing sdk and connect workflows — bounded by timeout-minutes: 20 and a cancel-in-progress concurrency group, the way the newer server and linux workflows are:

1. go build ./...
2. cross-compile linux/arm64, darwin/amd64, darwin/arm64
3. go test -count=1 -race -timeout 20m -skip 'TestNginxLogsOmitClientAddr' ./...
4. the quarantined nginx test, non-blocking
5. go vet ./..., non-blocking

Whole job is about 4 minutes.

No sibling checkouts

warp requires no urnetwork module and carries no replace ../ directives. It does not need the sibling-clone dance that sdk, connect, server and proxy do — a lone checkout builds. That makes this the simplest of the four Go CI PRs in this set.

The one thing to review: TestNginxLogsOmitClientAddr is split out as non-blocking

The first run of this workflow went red, and it found a real problem rather than a problem with the workflow. Worth reading before approving.

TestNginxLogsOmitClientAddr guards only on exec.LookPath("nginx") (nginx_test.go:236) and assumes whatever it finds can do stream. Its two siblings guard properly — warpctl/config_test.go:420 and lb/nginx_proxy_protocol_test.go:51 look for the pinned binary and check its version, and both skipped cleanly on CI. But the ubuntu-latest image ships nginx, so this one ran. The Ubuntu package builds stream as a dynamic module, and the standalone nginx.conf the test writes has no load_module line:

nginx: [emerg] unknown directive "stream" in /tmp/TestNginxLogsOmitClientAddr.../nginx.conf:19
--- FAIL: TestNginxLogsOmitClientAddr (10.07s)

Installing the repo's own pinned nginx does not fix it — it makes CI worse. make nginx_local in warp/lb builds 1.31.4 in about 5s with no extra packages (verified locally), but it configures --without-http_rewrite_module, and the test's config uses return:

nginx: [emerg] "return" directive is not allowed here in /tmp/TestNginxLogsOmitClientAddr.../nginx.conf:15

and the same build has no --with-http_ssl_module, which turns warpctl's TestNginxConfigValidation from a clean skip into a second failure on ssl_protocols. The full matrix, all measured:

nginx on PATH	stream	return (rewrite)	ssl_protocols	result
none (a clean dev machine)	—	—	—	all three tests skip, suite green
ubuntu-latest distro package	dynamic, not loaded	yes	yes	TestNginxLogsOmitClientAddr fails
make nginx_local pinned 1.31.4	yes	no	no	that test fails, plus TestNginxConfigValidation fails

There is no available nginx that makes this suite green. So the test goes into its own continue-on-error: true step — still run, still visible in the log, not gating — the way connect's workflow already treats its extender suite.

The real fix belongs in the repo, and the step's comment says so: give this test the same guard as its siblings (require the pinned binary, or check nginx -V for --with-stream before running), and widen make nginx_local to cover what these tests actually use — stream, rewrite and http_ssl. Remove the quarantine step once that lands.

Also skipped, and not pretending otherwise

warpctl/dynamo's client test needs real AWS credentials and is parked as XTestClient, which go test never collects. That is the repo's own decision, not something this workflow disables. No secret is referenced anywhere in this workflow.

Everything else is green

Nine packages, ~25s with the race detector on, covering warpctl config and run, the nginx log scrubber unit tests, supervise, services, grafana push/stats/alerting and the loki client:

ok  github.com/urnetwork/warp                  (minus the quarantined test)
ok  github.com/urnetwork/warp/config-updater   0.003s
ok  github.com/urnetwork/warp/grafana          8.074s
ok  github.com/urnetwork/warp/lb               0.002s
ok  github.com/urnetwork/warp/services         0.009s
ok  github.com/urnetwork/warp/warpctl          5.430s
?   github.com/urnetwork/warp/warpctl/cloudwatchlogs  [no test files]
ok  github.com/urnetwork/warp/warpctl/dynamo   0.003s [no tests to run]
ok  github.com/urnetwork/warp/warpctl/loki     0.030s

Verified against 678b25a (current main) both locally with Go 1.27.0 and on a real ubuntu-latest runner. actionlint is clean on the file.

Second pass: bounding, cross-compiles, -race, and a second pre-existing failure

Four additions after the first green run, each verified end-to-end on a clean ubuntu:24.04 before pushing.

concurrency + timeout-minutes. The job had neither, so a busy branch stacked runs and a hung job would have sat on GitHub's 6h default. Now cancel-in-progress and a 20 minute bound against a ~4 minute job, matching server/test.yml and linux/build.yml.

Cross-compiling the platforms this repo actually ships. warpctl, lb and config-updater each build linux/{amd64,arm64} and darwin/{amd64,arm64} from their Makefiles; grafana builds both linux arches. The native amd64 build never compiles supervise_darwin.go at all, so a darwin break was invisible here until someone ran warpctl on a mac. Compile-only, ~8s, nothing kept or published.

-race on the gating run. The repo's own test.sh runs with it, and supervise.go is a process supervisor — goroutines, signal handling and health-check timers are most of what supervise_test.go and the warpctl tests cover, and they are exactly the failures a plain run misses. Since those tests are timing sensitive, this was checked for flake before proposing it: clean over repeat runs, including on a CPU-throttled 2-core box with GOMAXPROCS oversubscribed. Costs ~10s.

go vet ./... — a second pre-existing failure, unrelated to nginx. vet is red on a fresh checkout of main:

warpctl/cloudwatchlogs/client.go:98:2: unreachable code

That line is a return nil sitting after a for { select { ... } } with no break. It is one dead line and no other package has a finding — but vet reports a dependency's diagnostic against every package that imports it, so warpctl cannot be vetted around it. Filtering it out the way connect/test.yml filters its extender package would drop the largest package in the repo out of vet entirely, which would be worse than not gating. So vet runs continue-on-error: true, reported but not gating.

This one is a genuinely trivial fix — delete that single line and the step can drop continue-on-error and become a real gate. It is deliberately not fixed in this PR, which touches nothing but .github/.

What a maintainer should decide

1. Keep -race? It is the repo's own test.sh habit and it is where supervisor bugs actually show up, but it is the one addition that could in principle flake on a bad runner day. Drop the flag if you would rather have the quieter signal.
2. Fix the two pre-existing failures, or leave them quarantined? The vet one is a one-line deletion. The nginx one needs a real decision about make nginx_local's configure flags (see above).
3. Two non-blocking steps is the ceiling. Both are permanently red rather than flaky, which is easy to stop noticing. They are worth closing out rather than living with.

One correction to a commit message

The first commit's body says "verified locally against 7c93c47". That SHA is wrong — the verification base is 678b25a. This repo's Default ruleset blocks both deletion and non-fast-forward on ~ALL branches, so it could not be amended after the first push. Noting it here rather than leaving it uncorrected.

Draft: opened alongside the equivalent PRs for glog, proxy and goidenticons so they can be reviewed as one set.