This repository was archived by the owner on Apr 22, 2023. It is now read-only.
Repository navigation
This repository was archived by the owner on Apr 22, 2023. It is now read-only.
Tool for generating/maintaining/auditing CODEOWNER file #27
Description
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.
Activity
joyeecheung commentedon May 26, 2018
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 commentedon May 28, 2018
@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 commentedon May 28, 2018
https://github.com/nodejs/node/blob/master/.github/CODEOWNERS
mhdawson commentedon May 28, 2018
@BridgeAR thanks !
jasnell commentedon May 28, 2018
Currently, the
CODEOWNERSfile 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
CODEOWNERSfile. It's a stop gap measure, but a useful one.Another idea would be having
git node landuse theCODEOWNERSfile to determine if anyone from the owning teams has reviewed the PR in question. That would, of course, require thegit nod landtool to know who is on each team, but, for instance, if the PR changeshttp2and no one from thenodejs/http2has reviewed, then the landing tool can emit a warning.joyeecheung commentedon May 28, 2018
@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 commentedon 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 commentedon 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 commentedon Jun 7, 2018
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 commentedon 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 commentedon Jun 7, 2018
I think we just need to make sure that the labels match the team names?
Trott commentedon Apr 22, 2023
Unarchived this repo so I could close all the PRs and issues. Will re-archive when I'm done.