kubernetes/test-infra: Prow job configs, Testgrid dashboards and the rest of Kubernetes CI

What kubernetes/test-infra is actually for

The repository describes itself as holding "tools and configuration files for the testing and automation needs of the Kubernetes project". That sentence is the whole scope. It is not a test runner, not a framework you add to a project's dev dependencies, and not a hosted service. It is the place where Kubernetes keeps the configuration that drives its CI and the dashboards that report on it.

The audience is narrow and specific. The README says Kubernetes uses a Prow instance at prow.k8s.io to handle CI and automation for the entire project, and that everyone can participate in a self-service PR-based workflow where changes are deployed automatically after review. So the primary reader is someone contributing job configuration to that instance, or someone running a comparable Prow deployment and looking for a working reference. If you are evaluating a test framework for a Python or JavaScript codebase, this repository has nothing for you, despite the generic name.

How the pieces fit: config in, Prow runs it, Testgrid and triage report

The README points at docs/architecture.svg for an overview of how the tools and services interact, and notes that the diagram is tracked as an updated issue rather than as a static document. The data flow described in the README is: job configuration lives in config/jobs, Prow consumes it and runs the jobs, and results surface in dashboards.

Two dashboards are about results. Testgrid at testgrid.k8s.io shows historical test results over time, and the testgrid directory holds that code. Triage at go.k8s.io/triage shows clusters of similar test failures across all jobs, and the triage directory holds that code. Clustering failures across jobs is the interesting part: a single broken test shows up in one place, but a shared cause shows up as a cluster, and that is what triage is built to surface.

Two dashboards are about jobs and pull requests. Deck at prow.k8s.io shows what jobs are running or have recently run. Tide, in prow/cmd/tide, has three views listed: PR Status shows what needs to be done to get PRs matching a GitHub Query to merge, Tide History shows what actions tide has taken over time to trigger tests and merge PRs, and Tide Status shows which PRs are in tide pools waiting to be tested and merged.

Around that core sit supporting tools. kettle extracts test results from GCS into BigQuery, and metrics runs queries against BigQuery to generate metrics from those results. boskos, which the README links to kubernetes-sigs/boskos rather than to a directory here, manages pools of resources, with CI leasing GCP projects from those pools. ghproxy, also linked out to kubernetes-sigs/prow, is a GitHub-aware reverse proxy cache meant to keep GitHub API token usage within rate limits. label_sync creates, updates and migrates GitHub labels across orgs and repos based on a labels.yaml file. gopherage manipulates Go coverage files.

Installing and a first real use

The README does not give install steps. There is no package to fetch and no binary to download from this repository. Installation, in the sense a reader usually means it, is not documented here; the README instead routes contributors into the job-config workflow and points at CONTRIBUTING.md for contribution rules.

The repository is a Go module, k8s.io/test-infra, and the Makefile defines the local test entry points. The unit target runs both language suites:

make unit

That target expands to go-unit and py-unit, which run hack/make-rules/go-test/unit.sh and hack/make-rules/py-test/all.sh respectively. The Makefile comments describe the unit tests as hermetic. A test target exists and depends on unit; an integration target is present in the file but commented out.

The Go module carries an explicit warning in its header comment, pointing at docs/dep.md before updating dependencies, and a second comment instructing contributors not to add replace directives to go.mod files in the repository, citing a Go issue about published packages. If you plan to depend on this module rather than contribute to it, read those two comments first; they tell you the maintainers have deliberately constrained how the module can be consumed.

For the config side, the README links three procedures in config/jobs/README.md: adding or updating jobs, deleting jobs, and testing jobs locally. Testing jobs locally before opening a pull request is the practical first use, because the README states that changes to the instance are deployed automatically once reviewed. There is no local dry-run command quoted in the README itself, so the exact invocation has to come from that linked README. Job triggering on pull requests goes through bot commands, documented at go.k8s.io/bot-commands.

Where the repository is thin, and where it is the wrong tool

The README is a directory of links, not a manual. It never explains how to stand up Prow, what the deployment topology looks like beyond a diagram reference, or how to run Testgrid against your own data. Several of the most important components are not in this repository at all: prow, prow/cmd/deck and prow/cmd/tide link to kubernetes-sigs/prow, ghproxy links to that same repository, and boskos links to kubernetes-sigs/boskos. The README lists them because Kubernetes CI uses them, but the code lives elsewhere. Anyone who clones this repository expecting a self-contained CI system will be confused by the first link they follow.

The automation model is also a constraint rather than a feature for most teams. Changes are deployed automatically after review. That works because a large group of reviewers and an oncall rotation exist around it; the README links an oncall page. A small team adopting the same layout inherits the layout without inheriting the review capacity, and the self-service model becomes a way to push a broken job config straight to production.

Finally, the name is a trap. Searching for test infra returns pytest-testinfra, Ansible-based server testing, and Python test infrastructure projects. Those are unrelated to this repository. The shared phrase is coincidental, and it is the main reason a reader lands here looking for the wrong thing.

What to use instead, and how the approaches differ

If what you want is a test runner for a Python or JavaScript project, pytest-testinfra is the closer match: it is a library you install into a project and call from test code, and it verifies server state. kubernetes/test-infra is the opposite shape. It is a Go monorepo whose main product is configuration plus services that watch a Git repository and react to pull requests. One is a dependency; the other is a control plane.

If you want the Prow control plane itself, the honest answer is that the components have moved. The README's own links for prow, deck, tide and ghproxy point at kubernetes-sigs/prow. This repository keeps the job configuration for Kubernetes' instance, the dashboards such as Testgrid and triage, and the supporting tools like kettle, metrics, label_sync and gopherage. So the choice is not between this and a competitor; it is between this repository and the sibling repositories it links to, and the README is explicit about which is which.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-09-23. The repository has no published GitHub releases, which fits the shape of the project: it is consumed as a Go module and as a set of deployed services, not as versioned artifacts you pin.

Licensing is Apache-2.0, and the Makefile carries the standard Apache header. The practical licence question for most readers is not the terms but the publishing constraint in go.mod: the header comment forbids replace directives in go.mod files in this repository and links a Go issue explaining why that is problematic for published packages. If you vendor or depend on k8s.io/test-infra, that constraint is part of the deal, and it exists to keep the published module usable by others.

Upgrade cost is dominated by the configuration surface, not by the code. Job configs live in config/jobs and are validated through the procedures in config/jobs/README.md, so the upgrade path is a pull request against those files rather than a dependency bump. The Go module has a documented dependency-update process in docs/dep.md, and the module comment tells you to read it before touching dependencies. Nothing in the README describes a rollback procedure for a deployed job config, so treat that as undocumented and plan accordingly.

Editorial conclusion

Adopt kubernetes/test-infra if you already run, or intend to run, a Prow instance and want the config layout, Testgrid and triage that Kubernetes itself uses; the README points contributors at config/jobs and at CONTRIBUTING.md. Do not adopt it as a general test framework: it is a Go monorepo of CI tooling and configuration, and the Python, Ansible and pytest-testinfra projects that share the phrase test infra are unrelated. Verify first that the Prow components you need still live here rather than in kubernetes-sigs/prow, since the README links prow, prow/cmd/deck and prow/cmd/tide to that separate repository.

Frequently asked questions

Official sources

1. Issues
2. kubernetes/test-infra on GitHub
3. License: Apache-2.0
4. README