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

Proposal: Support git providers other than GitHub in prow #10146

Open
wbrefvem opened this Issue Nov 14, 2018 · 4 comments

Comments

Projects
None yet
4 participants
@wbrefvem
Copy link

wbrefvem commented Nov 14, 2018

What would you like to be added:

Some sort of generic git service in prow that normalizes incoming webhooks into a generic format that hook and other plugins can understand, as well as provides a generic interface for performing git-related actions such as commenting on PRs, etc.

My initial proposal is that this git service essentially be another plugin that implements a number of generic git-related APIs, and that the name/location of this service be configurable so that we can support out-of-tree providers. In addition, it's probably worthwhile to think about decomposing the notions of code review and issue tracking into separate provider APIs, since not all providers implement these functions, although presumably prow will only ever be useful in combination with a git provider that at least provides basic code review features. But it would be nice to support, e.g., code review tool X in combination with issue tracker Y. We currently have something like this with the loose coupling of the Gerrit adapter and reporter. It would be great if we could make this sort of thing generic and extensible.

We discussed this briefly on the sig-testing call of November 6, and my hope is that this issue will be an asynchronous continuation of that discussion. I am also working on a more formal proposal that I plan to present on the weekly sig-testing call some time in the near future.

Why is this needed:

Currently, prow is tightly coupled to GitHub. Making it more generic would give the various k8s projects more flexibility in how they craft their workflows, as well as making prow more accessible to projects in the broader open source community and beyond.

/kind feature

@BenTheElder

This comment has been minimized.

Copy link
Member

BenTheElder commented Nov 14, 2018

cc @cjwagner @krzyzacy
/area prow

@yastij

This comment has been minimized.

Copy link
Member

yastij commented Nov 15, 2018

we might want to think about an interface that providers might want to implement.

@wbrefvem

This comment has been minimized.

Copy link

wbrefvem commented Nov 20, 2018

@yastij Yeah, there seems to be some consensus around this.

@wbrefvem

This comment has been minimized.

Copy link

wbrefvem commented Nov 20, 2018

Update

Here are some more concrete ideas on how to tackle this:

  • Implement a git service as a freestanding gRPC server
  • At least one webhook normalization method that would transform an incoming webhook into a generic event that hook can dispatch
  • Individual methods for various actions such as AssignIssue, CommentOnPR, etc.
  • Ship a default service that supports popular providers such as, but not necessarily limited to, GitHub, GitHub Enterprise, GitLab, Bitbucket.
  • Make protobuf package and .proto files available for users who want to implement their own service.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment