support Github-like CODEOWNERS? #4802

Closed
opened 2025-11-02 06:03:16 -06:00 by GiteaMirror · 9 comments
Owner

Originally created by @qzmfranklin on GitHub (Feb 6, 2020).

We are a team of ~15 engineers using gitea for daily development.

What is the attitude of this project towards supporting the github-like CODEOWNERS system or something like it?

To be honest, I'd find this functionality very useful.

Originally created by @qzmfranklin on GitHub (Feb 6, 2020). We are a team of ~15 engineers using gitea for daily development. What is the attitude of this project towards supporting the github-like CODEOWNERS system or something like it? To be honest, I'd find this functionality very useful.
GiteaMirror added the type/proposal label 2025-11-02 06:03:16 -06:00
Author
Owner

@lafriks commented on GitHub (Feb 6, 2020):

I think this is nice feature but it would require Gitea to have request review functionality first for this

@lafriks commented on GitHub (Feb 6, 2020): I think this is nice feature but it would require Gitea to have request review functionality first for this
Author
Owner

@lunny commented on GitHub (Feb 7, 2020):

Doesn't request review feature depends on this one oppositely? When a pull request submitted, we need find the code owners and send review requests.

@lunny commented on GitHub (Feb 7, 2020): Doesn't `request review` feature depends on this one oppositely? When a pull request submitted, we need find the code owners and send review requests.
Author
Owner

@mecseid commented on GitHub (Jul 7, 2020):

Do you have any update or plan when to implement this feature?

We want to use renovate to make dependency updates, but Gitea doesn't support to add reviewers for PR through API at the moment (or I didn't find it, but renovate doesn't implemenet this feature yet).

@mecseid commented on GitHub (Jul 7, 2020): Do you have any update or plan when to implement this feature? We want to use [renovate](https://github.com/renovatebot/renovate) to make dependency updates, but Gitea doesn't support to add reviewers for PR through API at the moment (or I didn't find it, but renovate doesn't implemenet this feature yet).
Author
Owner

@a1012112796 commented on GitHub (Jul 8, 2020):

Still doing, after #12039 and #11355 finished, I will try this feature, add some useful links about this issue.
github: https://docs.github.com/en/github/creating-cloning-and-archiving-repositories/about-code-owners
gitlab: https://gitlab.com/help/user/project/code_owners

@a1012112796 commented on GitHub (Jul 8, 2020): Still doing, after #12039 and #11355 finished, I will try this feature, add some useful links about this issue. github: https://docs.github.com/en/github/creating-cloning-and-archiving-repositories/about-code-owners gitlab: https://gitlab.com/help/user/project/code_owners
Author
Owner

@fossdd commented on GitHub (Jan 29, 2021):

Alright, seems that both PRs are merged. Any news on that? This feature would very nice!

@fossdd commented on GitHub (Jan 29, 2021): Alright, seems that both PRs are merged. Any news on that? This feature would very nice!
Author
Owner

@danninov commented on GitHub (Sep 6, 2021):

Added bounty! Bountysource

@danninov commented on GitHub (Sep 6, 2021): Added bounty! [![Bountysource](https://api.bountysource.com/badge/issue?issue_id=88138532)](https://www.bountysource.com/issues/88138532-support-github-like-codeowners)
Author
Owner

@6543 commented on GitHub (Jul 13, 2022):

copy from @C-EO (https://github.com/go-gitea/gitea/issues/20348)


Feature Description

Github gives big teams the ability to allocate people or group of people to certain files. This means that they have the absolute control over those files and have the final say on those files. Using the 'CODEOWNERS' file, I have been able to keep large teams organized on Github. I think it would be great if Gitea had that option too.

SCENARIOS

A user would create a file, probably named .CODEOWNERS, CODEOWNERS, .codeowners, or codeowners in the .gitea directory or in the top level directory of a repo.

The file would be implemented in such a format

# This is a comment.
# Each line is a file pattern followed by one or more owners.

# These owners will be the default owners for everything in
# the repo. Unless a later match takes precedence,
# @{user} and @{org}/{team} will be requested for
# review when someone opens a pull request.
*       @{user} @{org}/{team}

# Order is important; the last matching pattern takes the most
# precedence. When someone opens a pull request that only
# modifies JS files, only @{user} and not the global
# owner(s) will be requested for a review.
*.js    @{user}

# You can also use email addresses if you prefer. They'll be
# used to look up users just like we do for commit author
# emails.
*.js user@email.com
*.ts user@email.com

# Teams can be specified as code owners as well. Teams should
# be identified in the format @{org}/{team}. Teams must have
# explicit write access to the repository. In this example,
# the {team} team in the {org} organization owns all .txt files.
*.txt @{org}/{team} @{org}/{team-2} @{user}
*.js  @{org}/{team}
*.ts  @{org}/{team}
*.tsx @{org}/{team} @{org}/{team-2}
*.jsx @{org}/{team} @{org}/{team-2}
*.sh  @{org}/{team}
*.mdx @{org}/{team-2}
*.md  @{org}/{team-2}

# In this example, @{user} owns any files in the .github/workflows
# directory at the root of the repository and any of its
# subdirectories.
.github/workflows @{user} @{org}/{team}

# The `docs/*` pattern will match files like
# `docs/getting-started.md` but not further nested files like
# `docs/build-app/troubleshooting.md`.
docs/*  user@email.com
.github/ISSUE_TEMPLATES/* 
.github/PULL_REQUEST_TEMPLATE/*
.github/workflows/*

# In this example, @{user} owns any file in an apps directory
# anywhere in your repository.
apps/ @{user}
etc/ @{user} @{org}/{team}

# In this example, @{user} owns any file in the `/docs`
# directory in the root of your repository and any of its
# subdirectories.
docs/ @{user}

# In this example, @{user} owns any file in the `/apps` 
# directory in the root of your repository except for the `/apps/gitea` 
# subdirectory, as its owners are left empty.
/apps/ @{user}
/apps/gitea 

This would help keep the team organized and less confused.

The CODEOWNERS file can also be added to your codebase to help organize the developers better.

For further info, you could then use an icon like 'shield-lock' to show the developers who has charge over that file.

Screenshots

Web capture_13-7-2022_02522_github com
Web capture_13-7-2022_02654_github com

@6543 commented on GitHub (Jul 13, 2022): ## copy from [@C-EO](https://github.com/C-EO) (https://github.com/go-gitea/gitea/issues/20348) --- ### Feature Description Github gives big teams the ability to allocate people or group of people to certain files. This means that they have the absolute control over those files and have the final say on those files. Using the 'CODEOWNERS' file, I have been able to keep large teams organized on Github. I think it would be great if Gitea had that option too. # SCENARIOS A user would create a file, probably named **.CODEOWNERS**, **CODEOWNERS**, **.codeowners**, or **codeowners** in the _**.gitea**_ directory or in the top level directory of a repo. The file would be implemented in such a format ```yml # This is a comment. # Each line is a file pattern followed by one or more owners. # These owners will be the default owners for everything in # the repo. Unless a later match takes precedence, # @{user} and @{org}/{team} will be requested for # review when someone opens a pull request. * @{user} @{org}/{team} # Order is important; the last matching pattern takes the most # precedence. When someone opens a pull request that only # modifies JS files, only @{user} and not the global # owner(s) will be requested for a review. *.js @{user} # You can also use email addresses if you prefer. They'll be # used to look up users just like we do for commit author # emails. *.js user@email.com *.ts user@email.com # Teams can be specified as code owners as well. Teams should # be identified in the format @{org}/{team}. Teams must have # explicit write access to the repository. In this example, # the {team} team in the {org} organization owns all .txt files. *.txt @{org}/{team} @{org}/{team-2} @{user} *.js @{org}/{team} *.ts @{org}/{team} *.tsx @{org}/{team} @{org}/{team-2} *.jsx @{org}/{team} @{org}/{team-2} *.sh @{org}/{team} *.mdx @{org}/{team-2} *.md @{org}/{team-2} # In this example, @{user} owns any files in the .github/workflows # directory at the root of the repository and any of its # subdirectories. .github/workflows @{user} @{org}/{team} # The `docs/*` pattern will match files like # `docs/getting-started.md` but not further nested files like # `docs/build-app/troubleshooting.md`. docs/* user@email.com .github/ISSUE_TEMPLATES/* .github/PULL_REQUEST_TEMPLATE/* .github/workflows/* # In this example, @{user} owns any file in an apps directory # anywhere in your repository. apps/ @{user} etc/ @{user} @{org}/{team} # In this example, @{user} owns any file in the `/docs` # directory in the root of your repository and any of its # subdirectories. docs/ @{user} # In this example, @{user} owns any file in the `/apps` # directory in the root of your repository except for the `/apps/gitea` # subdirectory, as its owners are left empty. /apps/ @{user} /apps/gitea ``` This would help keep the team organized and less confused. The **CODEOWNERS** file can also be added to your codebase to help organize the developers better. For further info, you could then use an icon like 'shield-lock' to show the developers who has charge over that file. ### Screenshots ![Web capture_13-7-2022_02522_github com](https://user-images.githubusercontent.com/85847352/178598275-9f6c2fad-fdfa-4952-bba9-e624b1cb47fa.jpeg) ![Web capture_13-7-2022_02654_github com](https://user-images.githubusercontent.com/85847352/178598442-7f7b36d4-5cf3-49d0-966c-f1a53ca073ad.jpeg)
Author
Owner

@C-EO commented on GitHub (Mar 8, 2023):

When is this coming to Gitea? I have been waiting almost a year now.

@C-EO commented on GitHub (Mar 8, 2023): When is this coming to Gitea? I have been waiting almost a year now.
Author
Owner

@jolheiser commented on GitHub (Mar 8, 2023):

When is this coming to Gitea? I have been waiting almost a year now.

As soon as someone sends a PR and it gets merged. 🙂
Feel free to send one!

@jolheiser commented on GitHub (Mar 8, 2023): > When is this coming to Gitea? I have been waiting almost a year now. As soon as someone sends a PR and it gets merged. 🙂 Feel free to send one!
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#4802