Is it possible to set up gitolite acls to allow a user to read, write, and push, but not to delete branches?
You should be able to use as a general rule for all repositories:
repo #all
RWCD dummy-branch = foo
The 'D' is a "deletion" type of permission, which will authorize the deletion of a dummy-branch, but will make all your existing RW+ rule deny deletion (because they don't have a 'D')
Related
I would like to create a custom role in Github that inherits from the "Maintain" role and add the ability to merge pull requests without approvals. However, I do not want to give that role the permission to directly push to a branch. People with that role still have to create a pull request first.
The Github docs show the following permission, which only administrators have:
What is the name of that permission when I want to add it to a custom role? I can only find "bypass branch protections", but from my understanding that would give the role the permission to directly push to protected branches.
I have several questions on Github security
(1) For protected branches, is the Maintain Role, and the Admin role the only ones that can merge to it? I noticed Write can't do it.
(2) If I had a Team that had Maintain Access to my repo, why would I need that same team in CODEOWNERS file for approval? What is the use-case for using CODEOWNERS file then?
(3) Is there any way to enforce approval from the CODEOWNERS file, and not users who have WRITE or MAINTAIN access? Seems like those two groups can approve a PR also.
Regarding the first point ("For protected branches, is the Maintain Role, and the Admin role the only ones that can merge to it?"), since Feb. 2023, you have a new option/role:
Manage branch protection rules with a new permission (Feb. 2023)
You can now create a custom role to manage branch protections without having to grant the Admin role.
Previously, to manage branch protections you had to be an Admin which provides additional permissions that may not be needed.
For tighter control of Admin permissions, you can now craft a custom role that has the Edit repository rules permission, allowing just the right amount of access.
This permission grants the ability to create, edit, and delete both branch protection rules and protected tags.
For more information, visit Managing custom repository roles for an organization in the GitHub documentation.
We appreciate feedback on this in GitHub's public feedback discussions.
I want to enforce a policy at my azure repository where branch name should start only with feature/* OR hotfix/* etc. If any other name is given then it should not be possible to create that named branch.
so feature/test should be created but test should not.
Can you please help for it?
Thanks
I am afraid that there is no out-of-box method can enforce a policy at repo name.
For a workaround, you can restrict users to only create branches under feature by setting Repo permissions.
You can use tf command to achieve the goal:
1.Block the Create Branch permission at the repository root for the project's contributors.
tf git permission /deny:CreateBranch /group:[FabrikamProject]\Contributors /collection:https://dev.azure.com/fabrikam-fiber/ /teamproject:FabrikamProject /repository:FabrikamRepo
2.Allow users/groups to create branches under feature.
tf git permission /allow:CreateBranch /group:[FabrikamProject]\Contributors /collection:https://dev.azure.com/fabrikam-fiber/ /teamproject:FabrikamProject /repository:FabrikamRepo /branch:feature
If you want to limit users, you can change /group: -> /user:
For more detailed info, you can refer to this doc: Require branches to be created in folders
Is it possible for a specific user to bypass the review policies of a pull request?
For my specific scenario I am running NuKeeper on a pipeline and my Build Service user is successfully creating a pull request, but I'd like any PRs raised by this user to automatically bypass the required reviewers (but still go through the checks e.g. my build and test stage) - Is this possible?
The only other workaround I could think of would be to have a scheduled "master" pipeline which iterates over my repos and just merges all open pull requests from that particular user.
Is it possible for a specific user to bypass the review policies of a pull request?
You could add a account with higher permission, set Bypass policies when completing pull requests as Allow:
When we use this account to create a PR, this account can complete the PR directly without the approval of the reviewer.
Besides, there are a couple of ways to set up bypassing depending on how broadly you want to give someone rights to bypass. We are going to start with the narrower option which is allowing bypass for an individual branch or we could set it at the repo level.
You could check the document Azure DevOps Repos: Bypass Branch Policies for some more details.
In an AzDO project, I want to deny the group "all", that consists of 100 members, the right to contribute to the master branch.
However, 3 developers, that are also members of "all", should be allowed to contribute.
Unfortunately it seems "deny" always trumps "allow", so it seems I would have to create an extra 97 member group "all minus master contributors".
Creating such a group would be a royal pain just for a single project, but such groups would have to be created for every project in the organization. (The "all" group, in contrast, is managed organization-wide and can be shared between all projects)
Is there an easy way to accomplish what I want?
You can't override the "Deny" permissions. but, if they have "Not set" permissions they will not be able to push to the master, they should have "Allow" for this.
But, if you want to prevent users from push to master, the best way is to use Branch Policies instead of using the deny permission.
For the 3 users you want to allow push to master you can give Bypass policies when pushing permissions.
Steps:
open org setting->Permissions->create group A and add 100 members.
Open project setting->click the tab permission(All repo permission)-> add the group A and set the permission Contribute to Deny.
Open the repo->click the tab permission(one repo permission)->enter the user account(3 users) and change their personal permission Contribute to allow.
Then the 3 users can update the repo