Pirate Praveen 98b945ec52 New upstream version 13.9.3+ds1

2021-03-11 19:13:27 +05:30

5.1 KiB

Raw Blame History

type	stage	group	info
reference, howto	Manage	Import	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

Migrating projects to a GitLab instance

In addition to the specific migration documentation above, you can import any Git repository via HTTP from the New Project page. Be aware that if the repository is too large the import can timeout.

There is also the option of connecting your external repository to get CI/CD benefits. (PREMIUM)

LFS authentication

When importing a project that contains LFS objects, if the project has an .lfsconfig file with a URL host (lfs.url) different from the repository URL host, LFS files are not downloaded.

Migrating from self-managed GitLab to GitLab.com

If you only need to migrate Git repositories, you can import each project by URL. Issues and merge requests can't be imported.

If you want to retain all metadata like issues and merge requests, you can use the import/export feature to export projects from self-managed GitLab and import those projects into GitLab.com.

All GitLab user associations (such as comment author) will be changed to the user importing the project. For more information, please see the import notes.

If you need to migrate all data over, you can leverage our API to migrate from self-managed to GitLab.com. The order of assets to migrate from a self-managed instance to GitLab.com is the following:

NOTE: When migrating to GitLab.com, users would need to be manually created unless SCIM is going to be used. Creating users with the API is limited to self-managed instances as it requires administrator access.

Keep in mind the limitations of the import/export feature.

You will still need to migrate your Container Registry over a series of Docker pulls and pushes and re-run any CI pipelines to retrieve any build artifacts.

Migrating from GitLab.com to self-managed GitLab

The process is essentially the same as for migrating from self-managed GitLab to GitLab.com. The main difference is that users can be created on the self-managed GitLab instance by an administrator through the UI or the users API.

Migrating between two self-managed GitLab instances

The best method for migrating from one GitLab instance to another, perhaps from an old server to a new server for example, is to back up the instance, then restore it on the new server.

In the event of merging two GitLab instances together (for example, both instances have existing data on them and one can't be wiped), refer to the instructions in Migrating from self-managed GitLab to GitLab.com.

Additionally, you can migrate users using the Users API with an administrator user.

Project aliases (PREMIUM SELF)

Introduced in GitLab Premium 12.1.

When migrating repositories to GitLab and they are being accessed by other systems, it's very useful to be able to access them using the same name especially when they are a lot. It reduces the risk of changing significant number of Git URLs in a large number of systems.

GitLab provides a functionality to help with this. In GitLab, repositories are usually accessed with a namespace and project name. It is also possible to access them via a project alias. This feature is only available on Git over SSH.

A project alias can be only created via API and only by GitLab administrators. Follow the Project Aliases API documentation for more details.

After an alias has been created for a project (such as an alias gitlab for the project https://gitlab.com/gitlab-org/gitlab), you can clone the repository with the alias (e.g git clone git@gitlab.com:gitlab.git instead of git clone git@gitlab.com:gitlab-org/gitlab.git).

5.1 KiB Raw Blame History