Testbed status

Tests for OkHttp features that need real infrastructure behind them — containers to run against, or a network to reach out over. They run daily against published OkHttp artifacts, through the public API only, so the results compare versions rather than builds.

Results are grouped by the OkHttp version they were produced against, not by the workflow that produced them: the container suites and the Android ECH suite both testing 5.5.0-SNAPSHOT belong on one card. The pinned release is the version in gradle/libs.versions.toml, which every push and pull request tests; the scheduled runs add the current snapshot, so a regression on OkHttp's main branch shows up here before it reaches a release.

failing is either this repository being broken — suites run under the test task — or something unpredicted going wrong in a suite marked critical in the table above. Critical means the question that suite asks is one the repository is currently trying to answer, so a surprise there is the headline. The build still stays green: these suites record rather than gate, and it is this page that turns red, not the workflow.

findings is an unpredicted failure in a watch suite — one being kept honest rather than actively investigated, where a server this repository doesn't operate is as likely a cause as the client.

expected is a failure this repository predicted and can explain: the assertion is right and the answer is currently no, which is the finding rather than a problem with it. Examples include ECH on the JVM and monitor-based virtual-thread pinning before JDK 24. These are folded shut, and each carries its reason where a stack trace would otherwise be. When one starts passing, it becomes an unexpected pass to look at.

not run against a suite whose endpoint is down is the preflight doing its job: a public test server that has gone away reads as unavailable rather than as OkHttp failing. The Endpoints table above says which, and how long for.

The containers, network and android-ech workflows each upload the JUnit XML from every task they run, including the tasks that report without failing, and the network workflow adds what its endpoint preflight found. The pages workflow rebuilds this page when any of them finishes, collecting the most recent completed run of all three — so a container run finishing doesn't blank the ECH results, or the reverse — converts them to JSON, appends a summary to the history already published here, and redeploys the site. Nothing is committed to the repository: the deployed site is its own datastore.

The history strip keeps one block per published update, oldest on the left, capped at the last 120. Hover a block for its counts, click it for the workflow run behind it.

The raw data is served alongside the page — latest.json and history.json.