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

OWNERS files support for approving pull-requests before executing pipelines #1488

Closed
nagasree9 opened this issue Nov 30, 2022 · 10 comments · Fixed by #1516
Closed

OWNERS files support for approving pull-requests before executing pipelines #1488

nagasree9 opened this issue Nov 30, 2022 · 10 comments · Fixed by #1516
Labels
area/roadmap Issues that are part of the project (or organization) roadmap (usually an epic) kind/feature Categorizes issue or PR as related to a new feature.

Comments

@nagasree9
Copy link
Contributor

Feature request

I would like to have a github interceptor that blocks a pull request trigger from being executed unless invoked by an owner or with a configurable comment by an owner, for example /ok_to_test. Owners would be defined in an OWNERS file at the root of the repository

Use case

We have a few terraform modules in which a lot of developers from different teams contribute into. We run into situations where developers are first time contributors and it would be helpful to trigger a pull request pipeline run only after reviewed by an owner of the module. This would save the resources of the namespace for approved pipelines

@nagasree9 nagasree9 added the kind/feature Categorizes issue or PR as related to a new feature. label Nov 30, 2022
@dibyom
Copy link
Member

dibyom commented Nov 30, 2022

Related Work: we were building something similar for Tekton's own CI tektoncd/plumbing#482

@nagasree9
Copy link
Contributor Author

I have created a POC for the issue described and here is the link https://github.com/nagasree9/githubowners-interceptor

This cluster interceptor will check if the pull_request sender or the pull_request comment sender with body /ok-to-test is a member of organization or repository or the owners file. If either of these returns true the response to trigger is continue:true and would trigger the taskrun, if neither of these returns true the response to trigger is continue:false and would not trigger any taskrun

FYI - The enterprise example will not be useable unless changes are made, it is used for internal testing at the moment.

@dibyom
Copy link
Member

dibyom commented Dec 7, 2022

@nagasree9 thank you! I haven't gone through all the code but from looking at the examples this works the way I'd expect. I think we could potentially bikeshed on naming the paramters + how to specify the enterprise owners but those are minor issues.

I think it might make sense to see if we can add this functionality to the github interceptor we ship as part of triggers - the owner approval etc. will be optional fields - what do you think @khrm @savitaashture ? Also, are you open to contributing this to triggers @nagasree9 ?

@nagasree9
Copy link
Contributor Author

@dibyom yes, I am open to contribute into triggers github interceptor.

Could you please throw some light on what you are thinking areound with this "how to specify the enterprise owners".

@dibyom
Copy link
Member

dibyom commented Dec 9, 2022

@dibyom yes, I am open to contribute into triggers github interceptor.

Awesome!

Could you please throw some light on what you are thinking areound with this "how to specify the enterprise owners".

I was referring to supporting for GitHub enterprise and how that can be configured on the interceptor!

@nagasree9
Copy link
Contributor Author

@dibyom @savitaashture @khrm While integrating the owners feature into github interceptor should this code go into github.go (pkg/interceptors/github/github.go) or should it be a separate go file (pkg/interceptors/github/owners.go) of its own and call it into the github.go process. What is the recommendation here if there is a specific direction?

@khrm
Copy link
Contributor

khrm commented Dec 13, 2022

It's fine to use the same file.

@nagasree9
Copy link
Contributor Author

sure, Thank you

@dibyom
Copy link
Member

dibyom commented Dec 13, 2022

Yeah, we can split it out if necessary but using the same file sounds good for now!

@vdemeester
Copy link
Member

/area roadmap

@tekton-robot tekton-robot added the area/roadmap Issues that are part of the project (or organization) roadmap (usually an epic) label Feb 15, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/roadmap Issues that are part of the project (or organization) roadmap (usually an epic) kind/feature Categorizes issue or PR as related to a new feature.
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

6 participants