Skip to content
This repository has been archived by the owner on Apr 22, 2023. It is now read-only.

Tool for generating/maintaining/auditing CODEOWNER file #27

Closed
jasnell opened this issue May 15, 2018 · 12 comments
Closed

Tool for generating/maintaining/auditing CODEOWNER file #27

jasnell opened this issue May 15, 2018 · 12 comments

Comments

@jasnell
Copy link
Member

jasnell commented May 15, 2018

In the core repo we are experimenting with the use of CODEOWNERS file. It's going to require some maintenance and iteration to get correct. At some point, we may want to have some tooling to automate maintenance and auditing of the file so that it is correct.

There are also other ways the CODEOWNERS can be leveraged... For instance, ncu could include a git command that uses the CODEOWNERS file to identify who would be notified for any given set of commits.

@joyeecheung
Copy link
Member

For instance, ncu could include a git command that uses the CODEOWNERS file to identify who would be notified for any given set of commits.

I am curious, which commands could use that?
I thought about something for the release team to find proper backporters but have not reached the point where I can start writing code yet, but the owners specified by the CODEOWNERS file seems to be too broad in that case, at least not better than the "reviewer + author" group.

@mhdawson
Copy link
Member

@jasnell can you point to any doc or the existing CODEOWNERS files? I touch a quick look in the src directory but I did not see it.

@BridgeAR
Copy link
Member

@mhdawson
Copy link
Member

@BridgeAR thanks !

@jasnell
Copy link
Member Author

jasnell commented May 28, 2018

Currently, the CODEOWNERS file is of limited value because it will only do automatic notifications if the team or individuals have write access in the repository. Since most o our teams include people who do not have write access, GitHub does not automatically process the notifications. This makes me sad.

We could augment that by having the Github bot automatically do those notifications for us based on CODEOWNERS file. It's a stop gap measure, but a useful one.

Another idea would be having git node land use the CODEOWNERS file to determine if anyone from the owning teams has reviewed the PR in question. That would, of course, require the git nod land tool to know who is on each team, but, for instance, if the PR changes http2 and no one from the nodejs/http2 has reviewed, then the landing tool can emit a warning.

@joyeecheung
Copy link
Member

@jasnell Maybe we should replace the teams in CODEOWNERS with teams that have write access? Otherwise it does not seem to be useful to have them anyway.

@joyeecheung
Copy link
Member

joyeecheung commented May 28, 2018

By the way ncu already has code (for ncu-team) to know about members in teams and requires necessary access when creating tokens.

@refack
Copy link

refack commented Jun 7, 2018

I was wondering. If we're overriding GitHub, then we already have the bot doing it's black magic for tags. IMHO we should reuse that for @ mentioning teams.

@maclover7
Copy link

Along the lines of what @refack mentioned, would it be easier, for now, to avoid CODEOWNERS and handle all of this in github-bot? It already matches file paths to add labels to PRs, in theory we could do the same thing but just match to the relevant team(s) to ping. For example, if a PR edits http2 code (it will currently get the http2 label), and we could request a review from the http2 GitHub team.

@jasnell
Copy link
Member Author

jasnell commented Jun 7, 2018

So my only question there is how we would best manage those mappings in the GitHub bot. Otherwise tho, I'm perfectly fine with that approach so long as it works :)

@joyeecheung
Copy link
Member

I think we just need to make sure that the labels match the team names?

@Trott
Copy link
Member

Trott commented Apr 22, 2023

Unarchived this repo so I could close all the PRs and issues. Will re-archive when I'm done.

@Trott Trott closed this as completed Apr 22, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants