realaravinth/debian-mirror-gitlab
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
debian-mirror-gitlab/doc/user/group/import/index.md
Mohammed Bilal 6611f650cc New upstream version 15.6.4+ds1
2023-01-12 18:35:48 +00:00

13 KiB
Raw Blame History

stage group info
Manage Import To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments

Migrating groups with GitLab Migration (FREE)

FLAG: On self-managed GitLab, by default migrating group items is available. To hide the feature, ask an administrator to disable the feature flag named bulk_import. On self-managed GitLab, by default migrating project items is not available. To show this feature, ask an administrator to enable the feature flag named bulk_import_projects. On GitLab.com, migration of both groups and projects is available.

Users with the Owner role on a top-level group can use GitLab Migration to migrate the group to:

  • Another top-level group.
  • The subgroup of any existing top-level group.
  • Another GitLab instance, including GitLab.com.

Migrating groups using GitLab Migration is not the same as migrating groups using file exports. Importing and exporting groups using file exports requires you to export a group to a file and then import that file in another GitLab instance. Migrating groups using GitLab Migration automates this step.

Import your groups into GitLab

When you migrate a group, you connect to your GitLab instance and then choose groups to import. Not all the data is migrated. See:

Leave feedback about group migration in the relevant issue.

NOTE: You might need to reconfigure your firewall to prevent blocking the connection on the self-managed instance.

Connect to the remote GitLab instance

Before you begin, ensure that the target GitLab instance can communicate with the source over HTTPS (HTTP is not supported). You might need to reconfigure your firewall to prevent blocking the connection on the self-managed instance.

Then create the group you want to import into, and connect:

  1. Create a new group or subgroup:

    • On the top bar, select + and then New group.
    • Or, on an existing group's page, in the top right, select New subgroup.

  2. Select Import group.

  3. Enter the source URL of your GitLab instance.

  4. Generate or copy a personal access token with the api and read_repository scopes on your remote GitLab instance.

  5. Enter the personal access token for your remote GitLab instance.

  6. Select Connect instance.

Select the groups to import

After you have authorized access to the GitLab instance, you are redirected to the GitLab Group Migration importer page. The remote groups you have the Owner role for are listed.

  1. By default, the proposed group namespaces match the names as they exist in remote instance, but based on your permissions, you can choose to edit these names before you proceed to import any of them.
  2. Next to the groups you want to import, select Import.
  3. The Status column shows the import status of each group. If you leave the page open, it updates in real-time.
  4. After a group has been imported, select its GitLab path to open its GitLab URL.

Group Importer page

Automate group and project import (PREMIUM)

For information on automating user, group, and project import API calls, see Automate group and project import.

Migrated group items

The import_export.yml file for groups lists many of the items migrated when migrating groups using group migration. View this file in the branch for your version of GitLab to see the list of items relevant to you. For example, import_export.yml on the 14-10-stable-ee branch.

Migrating projects with file exports uses the same export and import mechanisms as creating projects from templates at the group and instance levels. Therefore, the list of exported items is the same.

Items that are migrated to the target instance include:

  • Badges (Introduced in 13.11)
  • Board Lists
  • Boards
  • Epics (Introduced in 13.7)
    • Epic resource state events (Introduced in GitLab 15.4)
  • Finisher
  • Group Labels (Introduced in 13.9)
  • Iterations (Introduced in 13.10)
  • Iterations cadences (Introduced in 15.4)
  • Members (Introduced in 13.9) Group members are associated with the imported group if:
    • The user already exists in the target GitLab instance and
    • The user has a public email in the source GitLab instance that matches a confirmed email in the target GitLab instance
  • Milestones (Introduced in 13.10)
  • Namespace Settings
  • Releases
  • Subgroups
  • Uploads

Any other items are not migrated.

Migrated project items

FLAG: On self-managed GitLab, migrating project resources are not available by default. To make them available, ask an administrator to enable the feature flag named bulk_import_projects. On GitLab.com, migration of project resources is available.

The import_export.yml file for projects lists many of the items migrated when migrating projects using group migration. View this file in the branch for your version of GitLab to see the list of items relevant to you. For example, import_export.yml on the 14-10-stable-ee branch.

Migrating projects with file exports uses the same export and import mechanisms as creating projects from templates at the group and instance levels. Therefore, the list of exported items is the same.

Troubleshooting Group Migration

In a rails console session, you can find the failure or error messages for the group import attempt using:

# Get relevant import records
import = BulkImports::Entity.where(namespace_id: Group.id).map(&:bulk_import)

# Alternative lookup by user
import = BulkImport.where(user_id: User.find(...)).last

# Get list of import entities. Each entity represents either a group or a project
entities = import.entities

# Get a list of entity failures
entities.map(&:failures).flatten

# Alternative failure lookup by status
entities.where(status: [-1]).pluck(:destination_name, :destination_namespace, :status)

Stale imports

Introduced in GitLab 14.10.

When troubleshooting group migration, an import may not complete because the import workers took longer than 8 hours to execute. In this case, the status of either a BulkImport or BulkImport::Entity is 3 (timeout):

# Get relevant import records
import = BulkImports::Entity.where(namespace_id: Group.id).map(&:bulk_import)

import.status #=> 3 means that the import timed out.

Error: 404 Group Not Found

If you attempt to import a group that has a path comprised of only numbers (for example, 5000), GitLab attempts to find the group by ID instead of the path. This causes a 404 Group Not Found error. To solve this, the source group path must be changed to include a non-numerical character using either:

  • The GitLab UI:

    1. On the top bar, select Main menu > Groups and find your group.
    2. On the left sidebar, select Settings > General.
    3. Expand Advanced.
    4. Under Change group URL, change the group URL to include non-numeric characters.

  • The Groups API.