With Gitolite we are able to set access restriction on tags. I have checked and it does not seem like GitLab does support it. Our Jenkins build user have been given access to push tags to git remote, but it does not have any other access to the repositories. Otherwise only repository owner(Master) can push git tags to remote.
Users should have full access to branches within their own namespace For instance as user should be able to create and push to remote the branch user/work Automatically without setting all users in each projects "Protected branches" user/* Set user read access to all projects within a group Does not look like "Group settings" have to feature in GitLab. torsdag 25. august 2016 08.41.17 UTC+2 skrev Sverre Moe følgende: > > One more thing I would like to add. > We have some git repositores names like utils++, which contains characters > not allowed in GitLab project name. > * Name can contain only letters, digits, '_', '.', dash and space. It > must start with letter, digit or '_'. > * Path can contain only letters, digits, '_', '-' and '.'. Cannot start > with '-', end in '.git' or end in '.atom' > > torsdag 11. august 2016 12.20.59 UTC+2 skrev Sverre Moe følgende: >> >> We have been reluctant to make the move over to GitLab because we still >> use Gitolite and want to continue to do so. >> I do keep my self up to date with changes in GitLab and noticed new >> feature in GitLab 8.7 >> >> Remote Mirrors (EE only) >>> You could already automatically mirror an external repository to your >>> GitLab instance. With GitLab 8.7 you can now do the inverse and have GitLab >>> push updates to a remote repository: a mirror on a remote repository >>> (!249). It's like you can have your cake and eat it too. >>> >> >> >>> This means that now you can use GitLab as the main place for your >>> development, and get all your changes pushed to another repository. There >>> are a number of reasons why it may be important to keep an existing >>> repository in addition to your new GitLab repository: >> >> * You can be tied with company policy to keep using the legacy system >>> * You want your existing git hosting service to keep playing the role of >>> showcasing your project >>> * You don't want to spend time reconfiguring all your existing >>> integrations >> >> >> >> Does this mean that we can continue to use our Gitolite server and mirror >> it completely in GitLab? Such that we can make use of Code Review and Merge >> request in GitLab and it will push/pull from/to Gitolite. >> > -- You received this message because you are subscribed to the Google Groups "GitLab" group. To unsubscribe from this group and stop receiving emails from it, send an email to gitlabhq+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/gitlabhq/d9e8b90a-0a68-4e8a-a2ec-841c81727465%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
