GitLab Remote Mirrors Gitolite

[Sverre Moe]

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.

[Drew Blessing]

The remote mirror feature will not work well if you're making changes on both sides. Inevitably there will be conflicts so the mirroring will stop at some point, until you manually fix the conflicts. IMO, you'd be better off migrating project by project and ripping off the band-aid. 

[Sverre Moe]

Unfortunately GitLab Shell is not feature comparable to Gitolite. There are some features from Gitolite we are using that are not supported in GitLab Shell and is preventing us to make the move.

[Drew Blessing]

What features in Gitolite do you rely on that GitLab doesn't have? We could create some feature requests, or maybe there are some ways we could make this work as it is now. I look forward to hearing your use-cases. 

[Sverre Moe]

I wrote something about it in a previous post.

Perhaps GitLab has gained some of these features since we last evaluated it. We previously evaluated GitLab 7.7, but I have kept myself somewhat up to date with new releases and features.

Our Gitolite/git administrator have comprised a list of features that we rely on with Gitolite. From what I can see GitLab does not support all of them.

Must have features:

* Manage users individually and in groups

* Define groups of repositories and allow group administration of repositories (give or limit access to many repositories for certain users), without having to add for each repository.

* Per-branch user access (none|read|write|create|delete|force-update)

* Tag access that can be controlled independently from branch and commit access (for instance, a user get access to push tags, but not commits)

* Namespace control for tags (a user gets access to push tags within a given namespace)

* General namespace control (gives personal namespace with full access within namespace for users and groups)

* Everything above must also allow for management individually per repository.

* Allow for command line management of git this setup. GUI is fine, but should not rely solely on it.

Gitolite has functionality that supports the above:

* Define repositories

* Define users

* Defines groups of users

* Auto defined user groups, for instance @all

* Define groups of repositories (include wildcard repositories systems/..*)

* Auto defined groups of repositories, like @all

* Define groups based on existing groups (but for instance minus/plus one or several users)

* Define access on all levels (repositories/users/groups/branches/tags/namespace)

* Access levels: none (deny), read, write, write+ (push -f), create, delete

[Sverre Moe]

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'

[Sverre Moe]

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.

[Sverre Moe]

I have one more that seems to lack in GitLab.

Set default protected branches on Group settings that would apply for all projects within that group

Protect master branch with write access only to Owner(s).

Current GitLab settings would require us to configure this for each project manually. We have aprox. 200 repositories.

[Drew Blessing]

Thanks for explaining your requirements, Sverre. Some of these GitLab now has support for, but some are not yet there. Are some of these issues that you can compromise on, in order to gain the many advantages of having Git repositories available in a Web UI, with merge requests and enhanced collaboration? Unfortunately, it will not be possible to continue using Gitolite alongside GitLab in the way you described in the initial post. 

[Sverre Moe]

I would have no problem to compromise on these missing issues, but our Gitolite administrator does. For the time being we refer to his judgement, but I hope we can make the move to GitLab EE in the future.

[Sverre Moe]

It been a while since last I checked into GitLab

We are still using Gitolite as our main git repository server, but with more emphasis on Merge Request and Code Review we eagerly want to use a tool that supports them.

There has been many new releases of GitLab since last I evaluated it over a year ago.

Checking GitLab I see I can configure each repository to either:

Pull from a remote repository, or Push to a remote repository.

I guess this can be used in conjunction with Gitolite?, to either

have GitLab update its repositories from Gitolite, or have GitLab push all changes back to Gitolite.

Pull from a remote repository
Set up your project to automatically have its branches, tags, and commits updated from an upstream repository.

 

Using this approach would mean we can not push directly to GitLab, as it also states in the documentation.

Since the repository on GitLab functions as a mirror of the upstream repository, you are advised not to push commits directly to the repository on GitLab. Instead, any commits should be pushed to the upstream repository, and will end
up in the GitLab repository automatically within a certain period of time or when a forced update is initiated.

Push to a remote repository
Set up the remote repository that you want to update with the content of the current repository every time someone pushes to it.

onsdag 21. september 2016 07.03.10 UTC+2 skrev Drew Blessing følgende: