-
-
Notifications
You must be signed in to change notification settings - Fork 10
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
Option Retrieve OWNERS from alternate sources #65
Comments
Can you make a separate issue for the multiple owners files suggestion, and provide an example of what you are hoping to see? Right now I would like to implement multiple owners files within the same repository, so that the owners file applies to just a subdirectory, but I think you are suggesting something different? |
I was thinking that we could make the owners file configurable as a github action input like so - uses: jpmcb/prow-github-actions@main
with:
# owners-file is a URL to the owners file to use to authorize the approve and lgtm commands
owners-file: https://raw.githubusercontent.com/ladygogo/test/main/OWNERS
prow-commands: |
/approve
/lgtm
github-token: "${{ secrets.GITHUB_TOKEN }}" When the github action specifies an owners-file, it should take precedence over the owners file at the root of the current repository. |
Cannot apply the lgtm label because Error: carolynvs is not a org member or collaborator |
Cannot approve the pull request: Error: carolynvs is not a org member or collaborator |
@carolynvs what youve got looks great to me! I was thinking I'd like to specify multiple owners files using a path or URL like this:
For multiple owners within the repo, just a relative path
|
Cannot approve the pull request: Error: asmacdo is not a org member or collaborator |
Cannot apply the lgtm label because Error: asmacdo is not a org member or collaborator |
I really do think that multiple owners files should be a separate issue and PR. There is a lot of complexity to match prow's behavior, and will require a bit more design and decisions before we can start implementing. I opened #61 to discuss how to even go about either replicating test-infra's logic in typescript or finding a way to call out to their go library from typescript. |
About the relative path for the owners file config setting. The way prow works is that the OWNERS file affects all the directories underneath where it is defined. Right now the prow github action only supports an OWNERES file at the root of the repository (so it applies to the entire repository). When we have support for multiple owners files, you can control the permissions separately in each subdirectory. Is that what you are looking to do in that example? |
We are hoping to have a single repository operator-framework/community that respects 3+ OWNERS files.
|
+1 - multiple owner files is a separate, more complex issue that I think deserves it's own issue to track. @carolynvs, this sounds like something you're looking at picking up? |
@jpmcb Yes, I would like to get feature parity of more of the owners file so that someone use to how it works with prow, can do most of the same stuff with the gh action. I had an open question on how you'd like to see that happen in #61. Boils down to do we want to try to reuse test-infra or just port the logic to typescript? |
Edit: moving this conversation into #61 😄 thanks for giving me a heads up on that one! |
Currently the path to the OWNERS file is hardcoded to the root of a single repository.
what I'd like
Allow the retrieval of the owners file to be configurable to specify a path or URL. (A URL would allow 1 owners file to apply to multiple repositories.)
why Operator Framework could use this
The Operator Framework is a federated project that could benefit from owners-file-based automation that is lighter weight than prow. We have multiple subprojects and subproject's OWNERS could be applied to multiple repositories.
stretch goal (separate issue?)
It would be nice to allow multiple owners files. For example operator-framework/community owners could be scraped from the owners files of multiple repositories. Seems like this could be done in 1 PR, but I'll create a separate issue if desired.
The text was updated successfully, but these errors were encountered: