On Sun, Dec 13, 2020 at 04:18:44PM +0000, Aoife Moloney wrote: > Hi everyone, > > Its been a few weeks but there are still two topics left to cover from > the original AMA session. This week's topic is Branches. As always, > below are some links to the original documents and chat logs from the > IRC session, and the main body of this mail is the questions and > answers pulled directly from the Q&A sheet that specifically relate to > branches. > * Questions and Answers hackmd link https://hackmd.io/RW8HahOeR7OJPON1dwuo3w > * Chat log from session > https://meetbot.fedoraproject.org/fedora-meeting-1/2020-09-10/ama_session_with_gitlab.2020-09-10-13.31.log.html > * AMA Blog post > https://communityblog.fedoraproject.org/gitlab-ama-follow-up/#more-9346 > * Here is this email in hackmd if you wish to view it there: > https://hackmd.io/me-0oLN-Qtmff1qMX2S-DA?view > > ## Topic: Branches > Force pushing - Protected Branches > - Question: Fedora forbids force-push in the main projects but allows > them in forks. Would this be feasible in GitLab in a way that people > cannot revert? > - Answer: This can be done with Protected branches, basically > (https://docs.gitlab.com/ee/user/project/protected_branches.html#protected-branches) > > Archived branches - Protected Branches > - Question: Fedora supports the concept of retired git `branch` (ie: > archived) that no-one can commit. Does GitLab have an equivalent > concept? (The retired status is not something project admins can > change) > - Answer: Yes this is possible with Protected Branches > https://docs.gitlab.com/ee/user/project/protected_branches.html#protected-branches > - Question: Extending to above question, the sla's or eol dates are > coming from a 3rd party service, when a user pushes to git branch, it > will check the eol in that service and rejects it if it is already > eol'd. Is this possible in GitLab? > - Answer: Instead of this we would probably use the Protected > Branches in GitLab. We could leverage the APIs to mass configure the > branches on eol dates. That would mean that for each git push we don’t > need to look at a 3rd party service to know if we can push or not. This would work for regular releases, but for module branches I'm not sure how it'll scale. > - Question: It is not allowed for users to delete the branches, only > certain people with certain access levels are allowed to perform this > operation. Is this possible in GitLab? > - Answer: Yes protected branches can be used here > https://docs.gitlab.com/ee/user/project/protected_branches.html#protected-branches > > Push permissions > - Question: In CentOS, members of a group (say: storage-sig) can push > to any branch starting with c<int>-<sig-name>-* (so for example, they > can push to : c8-storage-sig-v2.0 or c7-storage-sig), but they cannot > push to any other branches, like: c8, c7 or any of the branches > starting with c8-kernel-sig and so on. Would this be doable in GitLab? > (in a way that project owner/maintainer cannot edit?) > - Answer: A Custom Push Rule and server hook (pre-recieve Git > hooks behind the scenes) could help with this. > > - Question: Can we set permissions at branch level? Esp can we set > them with some regex matching? > - Answer: permissions accept wildcards, but not regexes. Regex can > be used with custom push rules. See > https://docs.gitlab.com/ee/push_rules/push_rules.html and > https://docs.gitlab.com/ee/user/project/protected_branches.html#configuring-protected-branches. > > Hiding branches > - Question: Is it possible to hide these retired branches from the UI? > Say, hide branch names with f30 or lower? > - Answer: This is not possible currently > > - Question: Currently a user is not allowed to rewrite the history. Is > it possible? It would be nice to allow only certain people to do so. > Although we might not use this, but its good to have just in case if > we ever need it. > - Answer: by default, only the `master` branch is protected > against force push and deletion. It’s possible to configure other > branches to be protected and who has permission to override. > https://docs.gitlab.com/ee/user/project/protected_branches.html#configuring-protected-branches Master or the default branch? > Branch level orphaning > - Question: Orphaning a package or repo? A maintainer (owner) of the > package can decide to orphan a package, the maintainer should only be > able to assign the package to the `orphan` user or any of the other > maintainers of the package only. Is this possible to set this branch > level as well? > - Answer: Yes, in the sense that who is allowed to push or merge > to a specific branch is controllable at the user or group level. This > can be at the specific branch level or based on a wildcard match based > on branch name. See configuring protected branches for more details. Pierre _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
