GitSwarm-EE 2017.2-1 Documentation


Repository mirroring

Introduced in GitLab Enterprise Edition 8.2.

There are two kinds of repository mirroring features supported by GitLab: push and pull. The push method mirrors the repository in GitLab to another location, whereas the pull method mirrors an external repository in one in GitLab.

By default mirror repositories are updated every hour, and all new branches, tags, and commits will be visible in the project's activity feed.

Users with at least developer access to the project can also force an immediate update with a click of a button.

A few things/limitations to consider:

Pulling from a remote repository

You can set up a repository to automatically have its branches, tags, and commits updated from an upstream repository. This is useful when a repository you're interested in is located on a different server, and you want to be able to browse its content and its activity using the familiar GitLab interface.

When creating a new project, you can enable repository mirroring when you choose to import the repository from "Any repo by URL". Enter the full URL of the Git repository to pull from and click on the Mirror repository checkbox.

New project

For an existing project, you can set up mirror pulling by visiting the Mirror repository page under the wheel icon in the upper right corner. Check the 'Mirror repository' box and hit Save changes at the bottom. You have a few options to choose from one being the user who will be the author of all events in the activity feed that are the result of an update. This user needs to have at least master access to the project. Another option is whether you want to trigger builds for mirror updates.

Pull settings

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 your project's configured synchronization time, or when a forced update is initiated.

If you do manually update a branch in the GitLab repository, the branch will become diverged from upstream, and GitLab will no longer automatically update this branch to prevent any changes from being lost.

Diverged branch

Pushing to a remote repository

You can set up mirror pushing to an existing GitLab project by visiting the Mirror repository page under the wheel icon in the upper right. Simply click the "Remote mirror repository" checkbox and fill in the Git URL of the repository to push to. Hit Save changes for the changes to take effect.

Push settings

Similarly to the pull mirroring, since the upstream repository functions as a mirror to the repository in GitLab, you are advised not to push commits directly to the mirrored repository. Instead, any commits should be pushed to GitLab, and will end up in the mirrored repository automatically within the configured time, or when a forced update is initiated.

In case of a diverged branch, you will see an error indicated at the Mirror repository settings.

Diverged branch

Forcing an update

While mirrors update at a pre-configured time (hourly by default), you can always force an update (either push or pull) by using the Update now button which is exposed in various places:

Adjusting synchronization times

Your repository's default synchronization time is hourly. However, you can adjust it by visiting the Mirror repository page under the wheel icon in the upper right corner. Check the Synchronization time section where you can choose to have your mirror be updated once every fifteen minutes, hourly or daily and then hit Save changes at the bottom.

Using both mirroring methods at the same time

Currently there is no bidirectional support without conflicts. That means that if you configure a repository to both pull and push to a second one, there is no guarantee that it will update correctly on both remotes. You could adjust the synchronization times on the mirror settings page to a very low value and hope that no conflicts occur during the pull/push window time, but that is not a solution to consider on a production environment. Another thing you could try is configuring custom Git hooks on the GitLab server.