I have an issue, I have a team (they are added into Github package's teams list with Write perm) of external developers, I want to restrict their ability to approve each other's PRs.
Meaning other team/users should be probably a different set of perms.
How can I do it? I wasn't able to find this on Github.
PS.
I tried adding this to .github/CODEOWNERS (also enabled require owner review)
* #company/company-devs some-special-developer
but #other_company/devs <- were still able to approve
Related
I have a repo in GitHub and I'm trying to get a handle on what permissions have been assigned to it. I am admin on the repo.
When I call gh api "https://api.github.com/repos/:org/:repo/teams" it returns the teams which have been assigned roles. Win!
However I know that some people have direct permissions applied to their users, not through a team. I want to see who these people are but can't find out how to do so through the API. I have nearly 300 repos to check so don't want to do it manually.
I know I could look through the contributors but my whole company has read rights to the repo so it's like to be hundreds of people and that sounds painful.
Is there a more direct way that I'm missing?
In GitHub or GitLab, to invite a collaborator, the administrator usually asks the collaborator's email.
Instead, how can the administrator allow anyone to request access through clicking a button on the GitHub / GitLab website?
I remember this was possible on at least one of these websites.
In GitLab, you can click on request access:
An email is sent to the most recently active project maintainers. Up to ten project maintainers are notified. Any project maintainer can approve or decline the request.
If a project does not have any maintainers, the notification is sent to the most recently active owners of the project’s group.
If you change your mind before your request is approved, select Withdraw Access Request
The OP Dean adds in the comments:
The maintainer can enable this by making the repo public but with visibility restricted to only project members.
With GitLab 15.8 (January 2023), that will trigger:
Create To-Dos for group owners on access request
Previously, access requests to a group appeared only in the Access requests tab in the Group members section.
Now, access requests also appear in the group owner’s To-Do List.
As a group owner, having access requests added directly to your To-Do List can help you manage your tasks more efficiently and add members quicker.
See Documentation and Issue.
And, still with See GitLab 15.8 (January 2023):
Create To-Dos for project owners on access requests
Previously, access requests to a project appeared only in the Access requests tab in the Project members section.
Now, access requests also appear in the project owner’s To-Do List.
As a project owner, having access requests added directly to your To-Do List can help you manage your tasks more efficiently and add members quicker.
See Documentation and Issue.
I have run into an issue where if my project managers are rushing, they sometimes will help move pull requests along by 'approving' them. As we have set the branch policy to require at least 2 approvals (and the creator cannot be one), this can be a bit of a frustration. I have moved the PMs into a new security group to isolate them from most options but I cannot find anything specific about Pull Requests. Does this just follow under the Contribute option or is there a specific way I can block them from being able to approve pull requests?
They have "Contribute to Pull Request" permissions, located under repo security settings. Remove that permission for the people you don't want to be approving PRs.
Is there a way to know which people have merge privileges on a public GitHub repository. If the owner is a user and not an organization, then at least I know one maintainer, but it's possible that there are other users with merge rights. Also, if the owner is an organization it is possible, that not all members of the organization have merge rights. So is there a way to find the exact maintainers?
Team privileges are not public in general. Even an organization-membership is not public since the publicity must be chosen by the given member, as the Documentation states:
,,By default, your organization membership visibility is set to private. You can choose to publicize individual organization memberships on your profile."
This partly applies for their implementation of CODEOWNERS, too. If it is up to date the given source file is annotated with a link to its responsible GitHub user.
However there's normally no need to know the individual maintainers of a repository (since every interaction with repos you're able to access is covered by the GitHub UI, which also assures that somebody takes care about your request). If your attention is about a public repository you might search the commits for accepted pull-request. But in that case you would preferably fork the repo and just generate pull-requests on your own.
You are even not able to contact an organization via GitHub - try to find their official website, contact them and ask for their maintainers if you need that information.
GitHub (since July 2017) now officially supports "code owners" for projects. Code owners are individuals or teams that are responsible for code in a repository.
Project maintainers can add a CODEOWNERS file to their repository to make it easier for others to identify code owners and have code owners be notified to review Issues and Pull Requests.
See the announcement post and help article for more info.
Just go to the team members tab within your repo, on the right it will describe what type of member they are. Ex: member or owner.
I have one collaborator in my private github repository. After she sent me a pull request, she could actually go to the pull request screen and executed a merge i.e. she had the privilege to merge her changes into my branch.
Is there some kind of setting that I need to set in order to make sure only I can do the merge? And, I don't think this is because my repo is private, right?
Thanks.
From 'https://help.github.com/articles/defining-the-mergeability-of-pull-requests/':
You can require pull requests to pass a set of checks before they can be merged. For example, you can block pull requests that don't pass status checks. You can also require that pull requests have at least one approved review before they can be merged.
By default, any pull request can be merged at any time, unless the head branch is in conflict with the base branch. But as your project matures and stabilizes, you can choose to enforce restrictions on how a pull request is merged into your repository.
Protected branches ensure that collaborators on your repository cannot make irrevocable changes to branches. These branches can also be protected by requiring pull requests to have at least one approved review before they can be merged.
You could use a service like PullApprove or required code reviews to ensure that you have to give permission first.
The "Manage multiple clients" GitHub help page mentions:
This approach lets you retain control over the repos, but still gives your clients access to them.
In many cases it is the cheapest route overall, though you will be stuck paying the bill yourself (unless you bill it to the client).
To use this strategy, upgrade your personal or org account to a paid plan.
Now you can add private repos for the client directly to this account.
If the client wishes to access the repos directly, they can create a free personal account and you can add that user as a collaborator (if the repos are on your personal account) or to a team (if the repos are on an org account).
With an org account you can also give them admin access to the repo if you wish.
So if your project was part of an org account instead of a personal account, you could have the choice the the admin access for the users you add as collaborator.