realaravinth/debian-mirror-gitlab
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
debian-mirror-gitlab/doc/user/project/repository/mirror/index.md
Pirate Praveen 9deebb8264 New upstream version 14.4.2+ds1
2021-11-18 22:05:49 +05:30

11 KiB
Raw Blame History

stage group info disqus_identifier
Create Source Code To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments https://docs.gitlab.com/ee/workflow/repository_mirroring.html

Repository mirroring (FREE)

Repository mirroring allows for the mirroring of repositories to and from external sources. You can use it to mirror branches, tags, and commits between repositories. It helps you use a repository outside of GitLab.

A repository mirror at GitLab updates automatically. You can also manually trigger an update:

There are two kinds of repository mirroring supported by GitLab:

  • Push: for mirroring a GitLab repository to another location.
  • Pull: for mirroring a repository from another location to GitLab.

When the mirror repository is updated, all new branches, tags, and commits are visible in the project's activity feed.

Users with the Maintainer role for the project can also force an immediate update, unless:

For security reasons, the URL to the original repository is only displayed to users with the Maintainer role or the Owner role for the mirrored project.

Use cases

The following are some possible use cases for repository mirroring:

  • You migrated to GitLab but still must keep your project in another source. In that case, you can set it up to mirror to GitLab (pull) and all the essential history of commits, tags, and branches are available in your GitLab instance. (PREMIUM)
  • You have old projects in another source that you don't use actively anymore, but don't want to remove for archiving purposes. In that case, you can create a push mirror so that your active GitLab repository can push its changes to the old location.
  • You are a GitLab self-managed user for privacy reasons and your instance is closed to the public, but you still have certain software components that you want open sourced. In this case, utilizing GitLab to be your primary repository which is closed from the public, and using push mirroring to a GitLab.com repository that's public, allows you to open source specific projects and contribute back to the open source community.

Mirror only protected branches (PREMIUM)

Moved to GitLab Premium in 13.9.

Based on the mirror direction that you choose, you can opt to mirror only the protected branches in the mirroring project, either from or to your remote repository. For pull mirroring, non-protected branches in the mirroring project are not mirrored and can diverge.

To use this option, check the Only mirror protected branches box when creating a repository mirror. (PREMIUM)

SSH authentication

Introduced in GitLab 11.6 for Push mirroring.

SSH authentication is mutual:

  • You have to prove to the server that you're allowed to access the repository.
  • The server also has to prove to you that it's who it claims to be.

You provide your credentials as a password or public key. The server that the other repository resides on provides its credentials as a "host key", the fingerprint of which needs to be verified manually.

If you're mirroring over SSH (using an ssh:// URL), you can authenticate using:

  • Password-based authentication, just as over HTTPS.
  • Public key authentication. This is often more secure than password authentication, especially when the other repository supports deploy keys.

To get started:

  1. In your project, go to Settings > Repository, and then expand the Mirroring repositories section.
  2. Enter an ssh:// URL for mirroring.

NOTE: SCP-style URLs (that is, git@example.com:group/project.git) are not supported at this time.

Entering the URL adds two buttons to the page:

  • Detect host keys.
  • Input host keys manually.

If you select the:

  • Detect host keys button, GitLab fetches the host keys from the server and display the fingerprints.
  • Input host keys manually button, a field is displayed where you can paste in host keys.

Assuming you used the former, you now must verify that the fingerprints are those you expect. GitLab.com and other code hosting sites publish their fingerprints in the open for you to check:

Other providers vary. If you're running self-managed GitLab, or otherwise have access to the server for the other repository, you can securely gather the key fingerprints:

$ cat /etc/ssh/ssh_host*pub | ssh-keygen -E md5 -l -f -
256 MD5:f4:28:9f:23:99:15:21:1b:bf:ed:1f:8e:a0:76:b2:9d root@example.com (ECDSA)
256 MD5:e6:eb:45:8a:3c:59:35:5f:e9:5b:80:12:be:7e:22:73 root@example.com (ED25519)
2048 MD5:3f:72:be:3d:62:03:5c:62:83:e8:6e:14:34:3a:85:1d root@example.com (RSA)

NOTE: You must exclude -E md5 for some older versions of SSH.

When mirroring the repository, GitLab checks that at least one of the stored host keys matches before connecting. This can prevent malicious code from being injected into your mirror, or your password being stolen.

SSH public key authentication

To use SSH public key authentication, you must also choose that option from the Authentication method dropdown. When the mirror is created, GitLab generates a 4096-bit RSA key that can be copied by selecting the Copy SSH public key button.

Repository mirroring copy SSH public key to clipboard button

You then must add the public SSH key to the other repository's configuration:

  • If the other repository is hosted on GitLab, you should add the public SSH key as a deploy key.
  • If the other repository is hosted elsewhere, you must add the key to your user's authorized_keys file. Paste the entire public SSH key into the file on its own line and save it.

If you must change the key at any time, you can remove and re-add the mirror to generate a new key. Update the other repository with the new key to keep the mirror running.

NOTE: The generated keys are stored in the GitLab database, not in the file system. Therefore, SSH public key authentication for mirrors cannot be used in a pre-receive hook.

Force an update (FREE)

While mirrors are scheduled to update automatically, you can always force an update by using the update button which is available on the Mirroring repositories section of the Repository Settings page.

Repository mirroring force update user interface

Resources

Troubleshooting

Should an error occur during a push, GitLab displays an Error highlight for that repository. Details on the error can then be seen by hovering over the highlight text.

13:Received RST_STREAM with error code 2 with GitHub

If you receive a "13:Received RST_STREAM with error code 2" message while mirroring to a GitHub repository, your GitHub settings might be set to block pushes that expose your email address used in commits. Either set your email address on GitHub to be public, or disable the Block command line pushes that expose my email setting.

4:Deadline Exceeded

When upgrading to GitLab 11.11.8 or newer, a change in how usernames are represented means that you must update your mirroring username and password to ensure that %40 characters are replaced with @.

Connection blocked because server only allows public key authentication

As the error indicates, the connection is getting blocked between GitLab and the remote repository. Even if a TCP Check is successful, you must check any networking components in the route from GitLab to the remote Server to ensure there's no blockage.

For example, we've seen this error when a Firewall was performing a Deep SSH Inspection on outgoing packets.

Could not read username: terminal prompts disabled

If you receive this error after creating a new project using GitLab CI/CD for external repositories:

"2:fetch remote: "fatal: could not read Username for 'https://bitbucket.org': terminal prompts disabled\n": exit status 128."

Check if the repository owner is specified in the URL of your mirrored repository:

  1. Go to your project.

  2. On the left sidebar, select Settings > Repository.

  3. Select Mirroring repositories.

  4. If no repository owner is specified, delete and add the URL again in this format:

    https://**<repo_owner>**@bitbucket.org/<accountname>/<reponame>.git

The repository owner is needed for Bitbucket to connect to the repository for mirroring.

Pull mirror is missing LFS files

In some cases, pull mirroring does not transfer LFS files. This issue occurs when: