It's 2030. What Does Prow Look Like? - Petr Muller, Red Hat

Prow entered the Kubernetes ecosystem when the project needed something GitHub couldn't provide: sophisticated merge orchestration, pluggable test execution, and fine-grained code ownership rules that scaled beyond what CODEOWNERS could handle. It solved real problems for a massive monorepo with hundreds of contributors submitting dozens of PRs daily. The question now is whether those problems still require a bespoke solution or if the platform has caught up.

GitHub merge queues fundamentally change the calculus. When Prow launched, you had two bad options: merge on green and deal with broken main branches when tests passed individually but failed when combined, or implement your own serialization logic. Prow's tide component provided that serialization plus batching, running tests against multiple PRs together before merging them atomically. GitHub's native merge queue now offers similar guarantees without running your own infrastructure. The implementation differs—GitHub rebases or merges PRs into a queue branch and gates on those results—but the outcome is comparable for most workflows.

The gap widens when you examine Prow's plugin ecosystem. The approve and lgtm plugins implement a review model that distinguishes between code review approval and merge authorization, letting repository owners delegate review responsibilities while maintaining merge control. CODEOWNERS approximates this but lacks the granularity. Prow's label-based automation, automatic issue triage, and slash commands provide workflow customization that Actions can replicate only through custom development. The question is whether that customization justifies the operational overhead.

Actions has matured significantly since 2020. Self-hosted runners now support autoscaling, ephemeral execution environments, and reasonable cost controls. For projects that previously needed Prow to orchestrate tests across heterogeneous infrastructure—different architectures, specialized hardware, air-gapped environments—Actions can handle much of this natively. The integration is tighter too. Prow requires webhooks, separate authentication, and its own UI. Actions lives inside GitHub's interface where contributors already work.

Where Prow still wins is complex merge logic and cross-repository orchestration. Kubernetes runs tests that span multiple repos, with dependencies that require coordinated merges. Prow's configuration-as-code model in a separate repo lets you version and review CI changes independently. The job execution model separates orchestration from execution, making it possible to run the same job definitions across different clusters or cloud providers without vendor lock-in.

The operational burden matters. Running Prow means maintaining a Kubernetes cluster, managing webhook delivery, debugging plugin interactions, and keeping up with API changes in both Prow and GitHub. For the Kubernetes project itself, this overhead is marginal—they already have the expertise and infrastructure. For smaller projects that adopted Prow because it was the Kubernetes way, the cost-benefit analysis has shifted.

The 2030 question isn't whether Prow should exist but what problems it should solve. If GitHub continues investing in merge queues and Actions capabilities, Prow's value proposition narrows to projects with genuinely complex requirements: multi-repo coordination, specialized hardware needs, or workflow customization that justifies the infrastructure cost. For everyone else, the boring platform features have become good enough. The challenge for Prow maintainers is deciding whether to compete on features or double down on the niche where bespoke tooling still wins.