Prow for a better Github experience

Have you ever worked on a project like Kubernetes and wondered how all things on Github were managed so nice and neat, with all pull requests labelled?

kubernetes/kubernetes open pull requests

It's prow, and it's amazing. The installation of prow is documented in Deploying Prow and won't be convered in the blog post, rather we'll take a look at prow configuration and a few of the plugins provided, namely:

config-updater
owners-label
trigger

Plugins

Prow supports configuring plugins per repository in your Github organization using the plugins configmap.

config-updater

The first plugin we'll have a look at is the config-updater:

The config-updater plugin automatically redeploys configuration and plugin configuration files when they change. The plugin watches for pull request merges that modify either of the config files and updates the cluster's configmap resources in response.

This is used in the kubernetes/test-infra to manage prows own config by re-deploying the plugins and config configmaps when changes occur to them.

kubernetes/test-infra config_updater plugin configuration

owners-label

The owners-label plugin helps labelling pull requests to better organize large projects using OWNERS files labels:

The owners-label plugin automatically adds labels to PRs based on the files they touch. Specifically, the 'labels' sections of OWNERS files are used to determine which labels apply to the changes.

This is used in the kubernetes/test-infra project to add different labels to Pull Requests depending on the areas of code that are changed. The project's top-level OWNERS file assigns the sig/testing label while the prow/OWNERS assigns the label area/prow. This makes it clear when filtering open pull requests the areas of code that were changed.

kubernetes/test-infra top-level OWNERS file

kubernetes/test-infra open pull requests

trigger

Triggers are prow configuration for jobs:

The trigger plugin starts tests in reaction to commands and pull request events. It is responsible for ensuring that test jobs are only run on trusted PRs. A PR is considered trusted if the author is a member of the 'trusted organization' for the repository or if such a member has left an '/ok-to-test' command on the PR.
Trigger starts jobs automatically when a new trusted PR is created or when an untrusted PR becomes trusted, but it can also be used to start jobs manually via the '/test' command.
The '/retest' command can be used to rerun jobs that have reported failure.

Prow is used to trigger a variety of jobs in the kubernetes/test-infra for example presubmits configuration. Triggers add arbitrarily named /slash command's to your Github organization for task automation.