Use Prow #2
olivercodes
started this conversation in
Proposals
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Background
In our recent EMPC wrap-up meeting with Rick, it was made clear that we'll be expected to both polish and rapidly drive adoption of the accelerator modules EMPC provides, and modify our strategy to include letting the markets "run with it", where "it" means the accelerators as we release them.
What is prow:
Prow is many things. For our purposes, it would be used as a means to delegate code ownership and programmatically accepting changes via asignee commands. It does quite a bit more than that, but for the purposes of this writeup I'm skipping that stuff.
Examples of it in use:
kubernetes-sigs/network-policy-api#51
In the above example, you can see I proposed a change to the network-policy-api repo. Ultimately, that change was accepted and merged. In order for that to occur, someone in this file: https://github.com/kubernetes-sigs/network-policy-api/blob/master/OWNERS
had to give it a
/lgtm
and/approve
, and earlier in the pr you can see where he gave it a/ok-to-test
which allowed my changes to gain access to test infrastructure. All of this was facilitated by prow.Proposal
Previously we talked about some lightweight open source (or "inner source" depending on the who) governance for this github org and potentially something like K8s Prow or similar to drive a simple and highly automated ownership/approval process for code changes to the growing number of repos in the org.
Prow, is highly centered around a pull request style process. Contributors fork the repo, make a change, and open a pull request to the upstream. Owners of that project (usually members of the SIG responsible for it) will then interface with prow in order to work with those change. You will often see comment commands like
/approve
/lgtm
/ok-to-test
/assign
/do-not-merge
etc. and prow runs in the background responding to these commands.Side story
It's interesting to know, that Prow is actually the reason github created this feature https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners, and was heavily inspired by it.
Concerns and Challenges
Implementation:
Luckily, I have some experience in this area. I deployed prow internally at my last company and rolled it out to hundreds of developers and many hundreds of repos. Prow itself runs on Kubernetes so it's quite straightforward to deploy. We may want to consider disabling some of it's features (like CI/Jobs) as the primary reason we're considering it in this proposal is for the delegation of repo ownership and governance around accepting changes from outside contributors.
If it's something we like, I'll get into more detail on impl in our next team meeting.
Final thoughts/musings
The solution might be overkill for what we have right now. But, that also means it will be much easier to implement now than in the future when we're under water. That said it's definitely not the only way to tackle this problem. I like prow because it was designed to deal with the fact that there are multiple pockets of loosely defined core teams that can be trusted (who are both internal and external members of various orgs) and given responsibility to their area of the project in a highly distributed and asynchronous manner.
It's also worth noting I have implemented it in a real enterprise setting (a quite restrictive one I might add, that was actually an Air-gapped version of Prow and Github Enterprise, ours is much easier to setup) with many dev teams. It's quite effective in helping facilitate an inner source (sorry for the buzzword) culture. It also helps keep us somewhat sane, as we continue to grow the number of repos and contributors keeping track of all the changes and things that need to be reviewed/accepted will get stressful.
Beta Was this translation helpful? Give feedback.
All reactions