Run the integration suite in CI

[pksgit]

CS-2036. Nothing behind the integration build tag has ever run on a pull
request, and test/ is not even compiled, so a build error there goes green
today. Found while adding an integration test in #480.

Two independent gaps

1. The integration job in build.yaml has a single step, docker build -f ./build/ingress/Dockerfile. It never invokes go test -tags integration.
2. build/test/Dockerfile copies only pkg/ and version/, so test/ is neither compiled nor linted. .golangci.yaml already sets build-tags: [integration], so the config was right all along; the files were never in the image for it to read.

What this does

build/test/Dockerfile also copies cmd/ and test/, builds the ingress
binary the suite spawns as its handler, and compiles the suite ahead of time so a
break under test/ fails the image. The existing Test job shares that image
and gains the same coverage for about 20 seconds.

build/test/entrypoint.sh gains an INTEGRATION branch that runs the prebuilt
suite. Without it the unit path runs exactly as before.

test-integration.yaml runs the suite against a Redis and a livekit-server
in dev mode, both containers on the host network. Dev mode supplies the
devkey/secret pair the generated config uses, so this needs no repository
secrets and works on a fork. That is a deliberate departure from the egress
workflow, which takes its config from secrets.EGRESS_CONFIG_STRING pointing at
a remote room server.

Redis carries this suite and nothing else, on purpose: any other service
registering an IOInfoServer on the same bus takes a share of the state updates
and the ingress under test never reaches a terminal state. A separate Redis
database does not help, since psrpc rides pub/sub and pub/sub is not scoped to
one. That comment is in the file so nobody folds it into a shared service later.

The matrix covers rtmp and url through the existing rtmp_only and
url_only config fields, so no new Go code. An INTEGRATION_TYPE selector of
the kind egress has belongs with the harness refactor in CS-2037.

Verified locally

Check	Result
docker build -f build/test/Dockerfile, lint stage uncached	exit 0, 0 issues with test/ in scope
Lint really reads test/	planted // recieve in test/url.go, rebuilt --target lint: failed with misspell, exit 1
go test -c -tags integration ./test/	compiles in the image
ingress on PATH, test.test present	both
RTMP publisher's GStreamer elements	flvmux, rtmp2sink, audiotestsrc, faac, videotestsrc, x264enc all present
Unit path unchanged (INTEGRATION unset)	go test ./pkg/..., 36 tests, 0 failures
rtmp leg with this workflow's config	PASS 48.1s, audio and simulcast video published
url leg	PASS 48.2s, 2 tracks

Draft, because one thing cannot be checked locally

Whether --network host behaves as expected on ubuntu-latest, and whether a
livekit-server container completes ICE with a handler in a sibling container
sharing that network. Both legs above ran natively against a local Redis and
room server, which exercises the config, the credentials and the publishers, but
not the container topology. This PR's own run settles it, since the paths filter
matches the files it changes.

Worth knowing before review

Green here means "did not error", not "media verified". Both tests end on
require.NotEqual(t, final.State.Status, ENDPOINT_ERROR) and each run produced a
single state update. Media did flow in both local runs, but nothing asserts it.
Pre-existing, and the clearest argument for the checkUpdate helper in CS-2037.

The url leg reaches devimages.apple.com, which RunURLTest has pulled since
Support for pulling URLs (#138). It is the only external URL in the Go test
code, and lighter than what egress already depends on.

WHIP is left out: its publisher is the livekit-whip-bot submodule, which has to
be checked out and built into the image first. Stated in the workflow rather than
left implicit.

redis:7-alpine and livekit/livekit-server:v1.13.6 are version-pinned rather
than digest-pinned, unlike the action SHAs and GSTVERSION.

🤖 Generated with Claude Code

[devin-ai-integration]

Note

This report is out of date. Scroll down for Devin Review's latest report on this PR.

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no bugs or issues to report.

[milos-lk]

what do you think about have a docker compose file like this:

# build/test/compose.yaml
services:
  redis:
    image: redis:7-alpine
    healthcheck: { test: ["CMD", "redis-cli", "ping"], interval: 1s, retries: 30 }
  livekit:
    image: livekit/livekit-server:v1.13.6
    command: --dev
    healthcheck: { test: ["CMD", "wget", "-qO-", "http://localhost:7880"], interval: 1s, retries: 30 }
  test:
    build: { context: ../.., dockerfile: build/test/Dockerfile }
    depends_on:
      redis: { condition: service_healthy }
      livekit: { condition: service_healthy }
    environment:
      INTEGRATION: "1"
      INGRESS_CONFIG_BODY: ${INGRESS_CONFIG_BODY}

The generated config then points at service names and it would allow us to easily share it between the CI workflow docker compose -f build/test/compose.yaml run --rm test and in magefile we could reuse that (by adding a target like: IntegrationDocker(configFile))