Prow-style directory-scoped OWNERS files

[asmacdo]

Support multiple OWNERS files across subdirectories with Prow's resolution semantics, replacing today's single root-OWNERS-only lookup.

Scope (agreed 2026-09)

Resolution — for a changed file, walk from its directory up to the repository root collecting every OWNERS on the way (child ∪ parents); options: { no_parent_owners: true } stops the walk. A root-only OWNERS therefore covers everything, which is exactly today's behaviour as a special case.

Authorization (single actor — "Model A")

• /approve on a PR: the commenter must be an approver for every changed file.
• /lgtm on a PR: the commenter must be a reviewer or approver for at least one changed file (Prow's lgtm rule).
• Issues (no changed files): root OWNERS as today.

Security — OWNERS files are read from the PR's base branch, never the head, so a PR cannot grant itself approvers.

Failure modes — fail closed: a changed file with no covering OWNERS is an error naming the file; any fetch/parse error is an error. Only when the repository has no OWNERS files at all does the existing org-member/collaborator fallback apply.

Parser — approvers, reviewers (lists of GitHub usernames), options.no_parent_owners; emeritus_* ignored; unknown keys tolerated.

Explicitly out of scope (future issues)

• Aggregated approval across multiple approvers with an approved label and coverage comment (Prow's approve plugin proper) — depends on the approved-label/merge-gate design.
• OWNERS_ALIASES.
• filters: per-path regexes, labels:.
• A configurable owners-file path/URL input (the original 2022 request; superseded by tree discovery — cross-repo/URL sourcing can return later as "where is the tree root").

History: #61 was closed into this issue.

[carolynvs]

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?

[carolynvs]

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.

[github-actions]

Cannot apply the lgtm label because Error: carolynvs is not a org member or collaborator

[github-actions]

Cannot approve the pull request: Error: carolynvs is not a org member or collaborator

[asmacdo]

@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:

- 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
       - https://raw.githubusercontent.com/gentlemangogo/test/main/OWNERS
    prow-commands: |
      /approve
      /lgtm
    github-token: "${{ secrets.GITHUB_TOKEN }}"

For multiple owners within the repo, just a relative path

- 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: 
       - ladygogo/OWNERS
       - gentlemangogo/OWNERS
    prow-commands: |
      /approve
      /lgtm
    github-token: "${{ secrets.GITHUB_TOKEN }}"

[github-actions]

Cannot approve the pull request: Error: asmacdo is not a org member or collaborator

[github-actions]

Cannot apply the lgtm label because Error: asmacdo is not a org member or collaborator

[carolynvs]

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.

[carolynvs]

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?

[asmacdo]

We are hoping to have a single repository operator-framework/community that respects 3+ OWNERS files.

• operator-framework/community/OWNERS
• operator-framework/operator-sdk/OWNERS
• operator-framework/operator-lifecycle-manager/OWNERS
• operator-framework/future-subproject/OWNERS

[jpmcb]

I really do think that multiple owners files should be a separate issue and PR.

+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?

[carolynvs]

@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?

[jpmcb]

Edit: moving this conversation into #61 😄 thanks for giving me a heads up on that one!