Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RepoKitteh-based selective CODEOWNERS enforcement on select subtrees #7423

Closed
htuch opened this issue Jun 28, 2019 · 14 comments · Fixed by #7743
Closed

RepoKitteh-based selective CODEOWNERS enforcement on select subtrees #7423

htuch opened this issue Jun 28, 2019 · 14 comments · Fixed by #7743
Assignees
Labels
api/v2 enhancement Feature requests. Not bugs or questions.
Milestone

Comments

@htuch
Copy link
Member

htuch commented Jun 28, 2019

As part of the stable API versioning initiative in #6271, we need to be able to ensure that @envoyproxy/udpa-wg has visibility on API changes and that @envoyproxy/api-shepherds sign-off on any API changes in the api/ subtree.

While we make use of CODEOWNERS in GitHub to allow more permissive management of extensions and the like, this mechanism is too coarse grained, since when we enabled mandatory CODEOWNERS sign-off along with b9a1b6e#diff-5daf978e60e03b3975b485d5f1b449dc, this resulted in all aspects of the Envoy tree requiring CODEOWNERS sign-off.

I think RepoKitteh could be a solution here. We would want the following behavior on api/

  1. When a PR contains changes to api/, @envoyproxy/api-shepherds are notified via a CC comment.
  2. When a PR contains changes to api/udpa, @envoyproxy/udpa-wg is notified via a CC comment.
  3. An additional GitHub check blocking merge is added that will only be marked as passing once an approval review is received from someone in @envoyproxy/api-shepherds.

I think 1/2 can turned into a general notification mechanism. We could implement them independent of 3, which could also be a mechanism useful elsewhere in the code base.

@itayd WDYT? CC @mattklein123 @caniszczyk for CNCF visibility.

@htuch htuch added enhancement Feature requests. Not bugs or questions. help wanted Needs help! api/v2 labels Jun 28, 2019
@htuch htuch changed the title Bot-based selective CODEOWNERS enforcement on select subtrees RepKitteh-based selective CODEOWNERS enforcement on select subtrees Jun 28, 2019
@htuch htuch changed the title RepKitteh-based selective CODEOWNERS enforcement on select subtrees RepoKitteh-based selective CODEOWNERS enforcement on select subtrees Jun 28, 2019
@itayd
Copy link
Contributor

itayd commented Jul 1, 2019

makes sense. let me figure out the timing.

@mattklein123 mattklein123 added this to the 1.12.0 milestone Jul 3, 2019
@htuch
Copy link
Member Author

htuch commented Jul 10, 2019

@alyssawilk I think this will also be useful for date plane change monitoring and review enforcement.

@itayd
Copy link
Contributor

itayd commented Jul 14, 2019

/assign @itayd

@itayd
Copy link
Contributor

itayd commented Jul 14, 2019

description makes sense, i'm working on it.

@htuch htuch removed the help wanted Needs help! label Jul 16, 2019
@htuch
Copy link
Member Author

htuch commented Jul 16, 2019

@itayd FWIW, if we can have the ability to extend this facility to other GitHub teams and paths, e.g. to monitor changes to source/common/http and require dataplane owners to provide reviews, that will be even better. But, I think if we can start with the concrete implementation mentioned in this issue, this is a good start, and we can iterate. Thanks for making this happen!

@itayd
Copy link
Contributor

itayd commented Jul 17, 2019

@htuch i see no other way than making it generic :) it's not much work, it's just configuration. i got it almost ready btw, will prolly finish it tomorrow.

@itayd
Copy link
Contributor

itayd commented Jul 18, 2019

@htuch is it ok if i label such prs with the team they mention? otherwise figuring out double-mentions on consecutive commits can be troublesome.

@itayd
Copy link
Contributor

itayd commented Jul 18, 2019

@htuch sans ^, things are ready. I just need to test a bit more. For that it'd be super useful if you could create a testers team in envoy that includes me. thanks.

@itayd
Copy link
Contributor

itayd commented Jul 18, 2019

@htuch fyi #7627

@itayd
Copy link
Contributor

itayd commented Jul 20, 2019

@htuch ready! demo for you: #7659

lmk if looks ok, then i'll make a proper pr to integrate into the repo.

@htuch
Copy link
Member Author

htuch commented Jul 22, 2019

@itayd looks great, this is exactly what we were after here I think. Can I confirm that the "must approve" checks are dynamic and shrink/grow/disappear based on PR and path?

htuch pushed a commit that referenced this issue Jul 29, 2019
Per #7423:

* When a PR contains changes to api/, @envoyproxy/api-shepherds are notified via a CC comment.
* When a PR contains changes to api/udpa, @envoyproxy/udpa-wg is notified via a CC comment.
* An additional GitHub check blocking merge is added that will only be marked as passing once an approval review is received from someone in @envoyproxy/api-shepherds.

Risk Level:
None. But if there is any issue, please revert.

Testing:
In test PRs under different users: #7659

Docs Changes:
None.

Release Notes:
None

Fixes #7423

Signed-off-by: Itay Donanhirsh <itay@bazoo.org>
@lizan
Copy link
Member

lizan commented Aug 8, 2019

@itayd I feel the comment is a little bit noisy, can we do following?

  • exclude Draft PRs until it is made ready for review
  • do not add comment on every commit, but just for the commit contains a change in the subtree

@mattklein123
Copy link
Member

@lizan FYI I already mentioned to @itayd the noise issue. Hopefully he will fix soon. The draft PR suggestion is a great idea also.

@itayd
Copy link
Contributor

itayd commented Aug 8, 2019 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api/v2 enhancement Feature requests. Not bugs or questions.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants